Looking for guidance from Epic on Pixar's OpenSubdiv -> USD/USDZ and the future of UE file formats

Development World Creation
1

Hey Epic,

I get the sense that you guys are mulling over the future of your geometry/mesh file formats right about now. It looks like OpenSubdiv didn’t make the 4.20 release which makes sense since UE currently doesn’t support any mesh file format to support it. [EDIT: OpenSubDiv DID IN FACT MAKE IT INTO 4.20]

I’m wondering, what’s the big picture here? One of your Trellos implies you have some of your big foreheads sweating over this. Good! The timing is perfect. To me is seems that an issue is that OpenSubdiv seduces you into using the USD/USDZ file format (which is great in itself) but then suddenly you’re awkwardly side-by-side with Hydra in some strange incestuous relationship. This might be OK for Apple / Adobe / Autodesk but seems to be dancing a little close to the fire for a company like Epic.

It’s probably not as bad as I’m making it out to be, but in a strategic sense adopting USD could be ceding really large swaths of future technical control to Disney (aka Pixar) if you just wholly adopt the format as the UE file format going forward. But I know you guys are smart enough not to fall into that trap, at least not directly.

I’m hoping you guys are planning on fully supporting this stuff yet sub-classing it in a way so that you can support other technologies (formats) as well. Personally, for dynamic environments I’m a big fan of more procedural approaches like the Grasshopper subsystem incorporated into Rhinoceros3D. To me that just seems like a perfect fit for UE. But in any case, externally-controlled file format support would be a really tricky beast, it might be problematic to support a plug-in approach due to legacy future support… I don’t know…

Hopefully we can kick off a healthy community discussion between people who are far smarter than I who can help inform developers where things are going while getting some early feedback. I have the feeling this is a big issue that might be rather important in the future.

cc: [USER=“35”]Tim Sweeney[/USER] just for grins

2

I’m no expert on these matters (eg I know nothing about USD/USDZ formats), but OpenSubDiv is used by the dev-geometry branch, and that branch got merged into master branch before master was used to make 4.20. So it is in there, at least on windows and for use with the subdivide feature of the experimental mesh editing tools that are in 4.20. Whether it can also be accessed in other ways such as via blueprints I cannot say, since I’ve not tried that stuff and documentation is lacking. Nor do I know anything about supporting it automatically for files imported from elsewhere. I do know that a refactoring of UE4 mesh asset code was part of the dev-geometry work too, but I dont know much detail.

3

Hey Steve thanks for responding. And on a Sunday! I probably should have added a disclaimer that I may be a bit ignorant on the exact situation here. I was following the dev-geometry branch and playing around with builds of that and built the Promoted branch as of a few hours ago and didn’t see it, at least not in the running app. But I might have my wires crossed or something… Oh jeez, you’re right - the source code is sitting right there. It has something to do with my build. I’ll look into that.

I’ll edit my question above since I should have checked before I asked.

4

Well the main issue,as you pointed out, is not so much about implementation in UE4 as it’s more of a case of a lack of any kind of standardization from with in the DCC type application and the lack of any software developer willing to adopted edit features that are unique to the application using someone else technology.

A good example is hardware based physics in UE4 is trapped in CPU bound rendering due to incompatibilities between ATI and Nvidia.

Second issue is the problem of Patent ownership as to who owns what formats and more important what the terms and conditions are covered under license even as being open sourced.

Granted USD/USDZ is covered under open source but what licensing format? MIT/CC)? If GPL game over as GPL is “not” compatible with GPL and is excluded.

Does the technology allow for interactive licensing? Interesting is that some application license excluded interactive use and 3d printing.

Sounds simple as from the tip of the iceberg perspective.

[100% opinion mode]

Just to be sure that we are on the same page we are talking about ?Meet the Experts: Pixar Animation Studios, The OpenSubdiv Project - YouTube

As a "game"engine Unreal 4 has taken a different direction by providing tools built into the edit environment that will take advantage of 3rd party applications that has been using advanced pipeline technology with out the need to reinvent the wheel but at the same time Epic is creating the path as UE4 being the final destination. The need for UE4 is to put into place the nuts and bolts by which other products can be “plugged in” and more than a few features have been add over time that really makes no sense until you look at iit all from the frame building perspective.

Two products which are very interesting is Unreal Studio and DataSmith, which is in Beta at the moment, where 3rd party formats that are questionable as an addition to the main UE4 product could be added to the pipeline into UE4 as to questionable fair use rights.

As I said I’m guessing but what is fact since 2013 OpenSubDiv, like all things software based, suffers from a case of obsolesce by design and the up-scaling of hardware solutions like GPU and CPU as well as run time optimization in UE4.

Sorry if I’m off the path but I really don’t see the value of adding run time sub division to a real time rendering environment that would be best done with in the DCC pipeline.

5

some of us are nit good at modeling and don’t have time to spend using 3ds max, if it can be done in the engine then why not do it in the engine

6

Wouldn’t runtime sub division be great for some types of cloth sims?

Mostly would be useful for non-traditional game art or assets using a lot of triplanar projection for materials. Not ideal for anything using baked normal maps.

Also potentially great for VR where anything could end up in a players face.

7

Well UE4 already has some level of Sub-division, just not as a single channel solution.

One can make LOD’s on the fly and import them as a component to the original geometry both static and skeletal.
One can use Auto_LOD to decrease the count.of a static object.(skeletal on the way as to rumors)
One can can use that fancy proxy LOD just added which would create the same sub-divided object per OP.
You can use materiel Tessellation of you want higher detail at run time.
Or decrease materiel complexity based on LOD level.

The thing is though is UE4 already does a very good job of optimization even at higher polycounts with out the need to decay fidelity of asset and then make an informed decision by profiling the environment to see where the actual work needs to be done.

Example

So with UE4 and a good graphics card the problem of moving polygons is solved a long time ago so a Pixar type solution for a video game is rather obsolete assuming that there is a need for Pixar style optimization.

8

Personally its the possibility of subdividing runtime procedurally generated meshes that is my area of interest.

9

Please keep in mind that SubDivision Patches will be one of the future building blocks for Apples graphics pipeline, with dynamic tessellation on (mobile!) GPUs. This will bring Gamer-PC performance to A-Series chips. But the reality still is - all content is made with high poly count TriMeshes. A big shift in the industry is needed. As well as more up to date tech knowledge.

10

Well then that’s as good a enough reason than anything else :wink:

11

There is an other benefit of runtime subdivision:
Character deformation would benefit hugely. Currently to achieve high fidelity deformation you either need lots of bones on a highres mesh or lots of corrective shapes.
With runtime subdivision you could focus on making a “lowpoly” version of the mesh look good using preview subdivision tools in your dcc, then in the engine it would look the same.
No need to deal with jagged edges from regions where either the mesh is too low res or the bones weights count exceeds 8 or having to mess around with dozens of corrective shapes and combine those with costume meshes, model variations etc. etc. It is a pipeline I used a lot when I was making 3d animations for films.

add: Material tesselation currently doesnt work well with meshes above 255 bone influences as it seems their internal materialID is split up by byte. So you get broken seams on the faces where the split happens.
A problem that I just realized is that for a proper subdivision algorithm to look really good it needs a quadded mesh, since meshes in UE4 are triangulated this will be a problem.