View in #pipelines on Slack
@il_berna: This USD stuff looks interesting but I have to admit… I still didn’t got it completely.
I mean, I tried a little to read what it is and what it does, but I have problems understanding it.
Maybe because I’ve never worked in the vfx or movie industry but in a relatively small gaming company.
USD seems to me an extremely complicated tool for our usual needs (basically assets export) and I really don’t see how it could fit in a pipeline like ours.
But I like the idea of an open format…
@David_Rhodes: Well, besides being open, it’s much faster than Fbx. That said, it doesn’t just represent individual assets—they are entire scenes with data separated as granular as you need/want. Variants, layers, nested references; these are very cool concepts.
Most game engines are not yet taking advantage USD, unfortunately. But imagine building entire levels or parts of levels in a DCC as an artist (looking at Solaris) and having designers work on their own layers in game editor and merging the two seamlessly (with intuitive conflict resolution).
@il_berna: Yes I’ve seen that it can basically contains full scenes with a lot of informations. It only seems to me that it’s way too much for basic small gaming field use… so I’m not sure if it could be worth the probably long time to understand,implement and try to use it
FBX is doing good atm for us, but in some cases it was actually slow and clunky:smile:
@kashaar: Hmm… Just spitballing here, but… Imagine automatically clipmapping geometry around the player/camera, and using virtual texturing to make a fully uniquely textured environment… You’d no longer need a concept of “assets”
@David_Rhodes: The whole concept (workflow) of authoring individual assets or modules in DCC, exporting, then bringing it into the editor and placing them there is so outdated and inefficient. Iteration requires two different softwares (at least) and you can never easily visualize a level in DCC to model in context, for example.
Not to mention all the changes that happen in editor can never go back to DCC easily. USD schemas could theoretically support bidirectional data transfer so that you never risk losing data due to conflict.
I’m not a USD expert, but I’m pushing for adoption in game development because current workflows are seriously archaic. Game quality expectations and sizes have grown, but tools and workflows have not really kept up.
@il_berna: @David_Rhodes your point is interesting. We still work with an old pipeline (model assets, export, import, build your environment).
Your wished workflow would require a vary radical shift from actual way of doing things. Mayebe we should all investigate that, to understand with time how the workflow could be evolved
@dhruv: So just a couple things:
usd can describe small assets as well. It’s just a data description and composition format at the end of the day. Anything you can describe in collada, fbx, alembic, JSON, XML etc can be described in USD
USD allows for a few things that alembic and fbx don’t, namely composition. That means anything from simple referencing and hierarchy, to overriding assets , describing asset variations/lods, shader graphs etc…
Typically those things would require a studio, even a small one, to make their own description formats or be tied to a specific engines formats. With USD you’re completely unbound and have a standard you can share.
It’s also extensible and open. That means you can make your own plugins to describe the data types you want or make plugins to handle a studios custom asset systems or to read non usd data like fbx. At the end of the day. With other formats you’d be making APIs and large pipelines on a layer above, with usd you build it in to your scene graph and can use it the same everywhere directly
So for a small studio, what does it give you over fbx?
You can scale your production easier when you’re no longer a small studio.
You can compose your levels in a format that every app will soon treat as a first class citizen. Which means you can have an artist affect one part of your level and see the entire level update for everyone.
With the exception of a few things that usd doesn’t describe yet by default, you don’t lose anything by shifting to an open standard. The things it doesn’t describe can be custom described by you like constraints and IK, they’re just not in by default
The biggest thing though is that all the studios regardless of size can stop reinventing the wheel and can focus on making the car.
@il_berna: The last point is very reasonable
I’ll try to find time to learn more about USD. In the future we could switch
@dhruv: The cost to switch to it will reduce over the next couple years. It still might be too early for smaller games studios without some dev budget.
The big film studios have switched because they can reappropriate the cost of building an alternative now. I suspect some larger games studios will be giving it a hard look soon now that a lot of big name projects are starting up for next gen.
The DCCs will majorly have support by next year. In the meantime there are plugins.
The major off the shelf game engines support it or will support it. Unity being the best example.
Many of the major industry hardware and software vendors are bought in as well. Apple, Adobe, Nvidia, AMD to name a few.
So hopefully within a year it’ll be relatively painless to use. Within a few years it has a strong shot at displacing alembic and fbx.
Gltf still makes more sense for webgl deployment. And I don’t see STL dying anytime soon
@il_berna: Thanks for clarifications pals