To try everything Brilliant has to offer for free for a full 30 days, visit brilliant.org/Acerola/ you’ll also get 20% off an annual premium subscription! #ad I got covid at siggraph so unfortunately I didn't have much time to create a cooler demo for you all making use of USD, but I hope you all like it! Be sure to speak up about a Godot integration if that interests you. Next video I'll be back on my goat stuff.
My colleagues would for sure be interested. So far I’ve found Unreal integration much less cumbersome than Unity and in my practice which is to work with small teams (less than 10) with variable levels of skills, implementing USD into production still isn’t really the thing. Even Remedy, who did a whole assed integration of USD for Northlight, are still progressively migrating from the good ol’ FBX pipeline. USD also introduces the problem of version control for the artists and it’s been the thing that has terrified all my colleagues who already struggle at the idea of merging a branch. So the overhead cost of educating your team and also make sure they can’t break stuff and that they understand the pipeline to fit in there really isn’t very practical, especially that the tools are new, unstable, and miss pretty big features such as rigging. The part I’m most interested in is the interoperability between the engine and the creation tool, aka you move a statue somewhere and the artist can work on it, moved, in their own program. Convenient. But great powers great responsibility etc. Since there isn’t a Houdini Engine for Godot, USD surely has some more extra attractiveness to it I think. However, Blender’s integration of USD also totally sucks and they don’t seem to want to make it anything else but a file format since Blender’s formatting is pretty antagonist to the logic implement in USD. So this is a big obstacle for the Godot integration since most of Godot users also are Blender users, for the sake of open source free programs. Before finally quitting school because I got a job instead, I wanted to make my dissertation about USD and quickly landed into the interoperability and version control problem. Without full interoperability and full version control (the API allows you to build one but it’s not that easy), it has little appeal over just doing as we always did: export the FBX and get the axis, the handedness and the scale wrong.
"there were 17 formats." someone: "we should make a new, universal format that can use everything." "there were 18 forma-- oh wait, people are actually using it universally? well damn."
But USD uses std and other compiler specific primitives in its C++ API, so it locks a user to a specific compiler, and not just compiler but a compiler version -- one can't use their DLL/LIB, as the ABI won't be compatible. So, a user must compile the whole USD locally for the specific compiler / version. Good luck debugging sporadic crashes (because of ABI incompatibility) if someone forgets to push right lib/dll 🙂
@@chidorirasenganz yeah and then refuse to use or implement it for years and years! What geniuses! And if they make it a closed standard then they can gatekeep it too for MAXIMUM PROFIT!!!!
I feel like this is, if anything, underselling what USD can do. From USD files potentially being human readable and editable, to the ability to use hydra to plug a USD scene directly into most render engines, to the ability to layer USD scenes across multiple files, editable across multiple users and different software in parallel, it is an absolute beast. And that's just the benefits I've noticed as an artist with zero pipeline or coding experience. It was a magical moment the first time someone opened a USD ascii file in front of me and created a basic PBR material by just typing the values into notepad.
Python isn't fast, but if it's that slow, you're just a bad python programmer. I find it hilarious that one of main mantras of python is "there should be only one way to do things", but everything in python can actually be done 9 different ways, 8 of them are obvious and slow as f, and one is obscure, but fast(er)
@@gorak9000 you make python fast, by cheating*! *cheating by just offloading the actual computation part to C code, and using CFFI to import the result back to python-land
Alan Wake 2 (well NorthLight) used USD files for their entire game. It allowed them to do live editing from Maya, to the editor, to the game. They put out a few videos when Alan Wake 2 launched about the new features to their engine
@@Hecktic117not sure what is up with TH-cam, I tried twice to post the link. Go to remedy games’s website and click on Northlight Engine, that has most of the videos on various blog posts
I'm not a 3D dev, but seeing open-source standardization like this is really exciting. Much love to the talented people working to make development more accessible, universal, and user-friendly!
Actually not knowing something when a video is titled "X You've never heard of" is the death of my ego. 99% of the time it's clickbait where they're just talking about something everyone knows of and I get to be a smug prick about it.
It being something new is the dream scenario. In this case I thought, "Isn't that just USD? That's not so obscure…" before clicking the video. And sadly I was right, no new knowledge for me~
7:20 A small correction: right-handed and left-handed coordinates are actually the opposite of what's shown in this video. Handedness isn't about what axis points up but about the relationship between the axes.
GLTF came out 8 years ago and we thought it would be the universal standard. Pixar released USD and seemingly everyone jumped on the hype train and forgot about GLTF and now there's 2 competing standards
They're really not that comparable. GLTF is more of a transmission format while OpenUSD is more of an interoperability format that targets large-scale entire scene data in a way that makes collaborative editing easier. A comparison I've seen a lot of is OpenUSD is to PSD as GLTF is to JPEG/PNG, you likely wouldn't ship the product using OpenUSD, but OpenUSD contains a lot more functionality and data than GLTF and thus has added value during the creation of the product. GLTF has it's advantage in the realtime rendering and loading aspect of a game, while OpenUSD has it's main value in the production pipeline, while both represent collections of objects and data, that serve different purposes. It wouldn't be uncommon to see people develop a game in OpenUSD, then convert to GLTF for distribution.
7:14 correction: in a z-up right handed coordinate system, y points away from the viewer. take your right hand, point your thumb (x) to the right and your pointer finger (y) away from you, and you'll see that your middle finger (z) points up. In Unitys left handed y up coordinate system, z points away from the viewer.
Studying physics in uni we were dissuaded from the classic right hand rule and encouraged to use the thumb rule instead (which still depends on which hand you use... but the convention is right). If you curl your fingers from the first axis towards the second axis, your thumb will point in the direction of the third axis. Maybe this is just habit, but i've come to feel this is easier to remember. Instead of making your hand into a strange shape, it's like you're just grabbing the z-axis and utilizing the natural directions of your fingers.
Veggies for dinner(always, to enter intermittent fasting and get rid of stubborn fat), protein based lunch and breakfast(meat, eggs, little of fish), cut carbs to a minimum(if you want to eat a pizza a week, go ahead reward yourself). For volume max 9+- reps; for stamina, strength and "leaniness" go fo 15+-; dont mix them in a fast pace, one week one and the next week the other. Surprisingly doing various sets doesnt do much, the one that gives more its the first one, its better be consistent than giving up so you can start at the first reps and adapt to it(dont go overboard, or youll give up by your own expectations). Good luck!
Since you're a shader guy, I would appreciate a followup video where you show how to author a shader and it's material instances entirely inside USD, and then have it appear in Unity or Unreal or wherever. IMO using mesh generation as an example application of USD really misses the mark and undersells it. 20 years ago I wrote code to generate OBJ files procedurally, because OBJ is a really easy format to generate to store verts, faces, normals, etc. In my mind, the powerful thing about USD is the non-geometry features, so I would like to see you cover it from that perspective.
YT recommended this video and I instantly clicked because of the title. As soon as I started watching the video I went, "Isn't that the grass guy?" from your video about how games render so much grass from 2 years ago lol. I guess you are just super unforgettable. Nice video btw.
Yes the physics API is super super simple. You are basically just annotating objects with the bare minimum number of properties needed for rigid body physics. So collider shapes, mass, etc. Also USD does not provide a specification or handle the actual physics simulation. I.e. there is no physics engine. Thats on the developer to implement in their software that is consuming the USD.
@Acerola_t for real though, trying to export/import rigs from an older game for modding made me hate every single general purpose 3d model/rig file format that exists
@@TheCrewExpendable Thanks! I was wondering how that "it supports physics" worked. So it supports describing initial conditions, not running the simulation.
14:48 Interesting, I remember you talking about Godot not really having the support for the graphics-heavy stuff you want to do a while back. Has something changed in that regard?
yeah unity continues to nose dive at every single turn and godot only keeps accelerating -- I want to provide value to my community, and I don't think that's with unity anymore
My experience clicking on this video was something like this: “Ah finally my VFX degree comes in use, they must be talking about FBX” “OpenUSD” “Ah, bollocks”
Yeah, that's the first example I saw of this technique. It's a very clever trick that works without making the ads more obtrusive. And since that makes this an objectively better way to do advertising, clearly the entire ad industry should be moving to this new cute animal standard.
Funny coincidence, as Godot just recently released 4.3 update featuring improved FBX support instead. Understandably so, since rigging is very important
Skeletal meshes are supported in USD by the way, just like they are in FBX. I think the missing rig definition he is talking about is the actual whole rig with controls and deformers. This means you can bake your animation on the skeleton in maya and export it wherever you want, but not export the whole rig from Maya and animate it wherever you want
3 shader formats for the rendering kings under the sky 7 texture formats for the sculpting lords in their halls of tablets 9 model formats for outdated engines doomed to die One format for the dark animatiors on their dark chairs In the land of pixar where the shadows lie One format to rule them all, one format to find them One format to bring them all, and in the darkness bind them In the land of pixar where the shadows lie
Your videos really keep coming around at the perfect time for me! I'm building a 3D "Engine" ontop GameMaker Studio 1.4 and have just finished my PBR shader. I found myself writing a custom set of scripts to delineate surface material values, and every time I re-invent the wheel like this I ask myself: "How is everyone ELSE doing this?" Sometimes It's actually a bit comforting to know that -up until recently- everyone was just ramshackling their own solutions together just like I did.
There's a push for it, and I think some people are poking at it. GLtf does most of the same more efficiently, and on roughly the same standards, though, so I'm not too worried about it.
@@PySnekdifferent use case. USD will be more of a replacement to the Godot scenes. Ofcourse you CAN uae gltf for scene authoring, but USD fits the purpose much better.
@@askeladden450 Than just update FLtf to cover scenes instead of putting so much effort in a new standard... I just don't get it and it's always the same story.
And to think the Amiga had IFF interchangeable file format back in the 90s. Not a 3D format, but an example of having universal formats. IFF, the “Interchange File Format” standard, encourages multimedia interchange between different programs and different computers. It supports long-lived, extensible data. It’s great for composite files like a page layout file that includes photos, an animation file that includes music, and a library of sound effects.
Is fun to see how a field that started in the early early days of the internet diverged so much that integration/standardization is only lately been adopted. There are some other fields were integration came right away. Is fascinating to see. Lovely work.
I hate it when developers get annoyed at people calling something a "file format" when there is no a better word available and when it essentially _functions_ like a file format as far as the end user is concerned.
Your channel is awesome! I've been everything from a jr gameplay programmer up to senior tech artist at FAANG and still find your content always has things to learn for every skill level, and its also lots of fun. Now I just need to get the rest of the 3D world on my Quaternions > Matrices hype train as the core approach to rotations in modern engines...
I see that the standard has various extension mechanisms. Probably necessary, given the functional impossibility of covering everyone's use case; but the sort of thing that makes you a trifle nervous about interoperability in practice. Are the tools that support the standard pretty good about sticking to a well-formed core of mutual understanding; or do you run into a pretty significant risk of finding opaque vendor blobs that are 'standard' in the sense that they obey the standard's specifications for embedding and talking about arbitrary blobs; but more or less profoundly unhelpful if you are trying to interact with output from certain tools; or move between tools with their own opinions on vendor specific formats? I'm think of the (admittedly much more beige and blandly corporate) instance of when office documents largely went from the old binary formats to the new-hotness 'open' it's-just-a-zip-file-with-XML-isn't-that-great; but documents that were nothing but a bunch of OLE blobs that couldn't even be moved between computers with different OLE handlers; much less cross-platform, were technically 'open' so long as the XML telling you that the thing was just rammed full of blobs was well formed); or the...unfortunate...discrepancies you can run into between PDF as in ISO 19005 and 'PDF' as in whatever Acrobat feels entitled to emit.
This is very interesting, but I also am wondering, how about collaborative editing? something like git for 3d modelling? something like that must exist in major companies like Pixar because I don't know how they are working together on the same scenes
There's one guy modelling one asset. Juniors will model simpler stuff like props and seniors usually work on hero assets like characters and what not. The layout/lighters can easily import those models after and create a scene based on the descriptions.
Interesting, so that means there is also one guy on the scene itself? Or is that something that is shareable? (Technically you can use git here with the usd format i guess so that might be it)
Collaboration is made easier with the possibility to cut the scene in multiple files a lot of way. One of the aim of the nvidia omniverse platform is facilitating a git-like behaviour with a file server enabling file history and reference to older versions of the file. It also has live editing capabilities directly on the same scene, that I don't think are standards but are quite open via quite a few of extensions bringing them in other tools
7:20 that's the left hand coordinate system you're describing. Curl your left or right hand with the thumb sticking out, as if you were giving a thumbs up👍 to someone. The four curled fingers show the shorter directed angle from OX to OY half-axis, and the thumb points to where the OZ half-axis should be. If it's the right handed coordinate system, then the right hand will show the OZ half-axis, if it's the left handed coordinate system, then the left hand will show the OZ half-axis
This video was enjoyable and informational Never knew this existed till now Well done you have earned my subscribe I'm glad that this is a thing in this world where so many programs have their own file format... Glad there I something uniting them all, and hopefully soon this will be standard in every program Thank you for making this video and telling the world about OpenUSD Have a Great Day Acerola, and I can't wait to see what you make next 🖖
I feel like reading the XKCD cartoon about adding one more universal format to end all formats! I think innovation is too dynamic and CGI too complex for all use cases to be compatible with a single data format. It can only be like Word vs Libre Office Write files. Roughly compatible, but tons of small implementation differences and some data that doesn't fit and is lost.
It doesn't have to cover all possible usecases though. Simply providing a format that covers most basic concepts and is understood by all programs is already incredibly useful. You can still have program-specific usecases (like the displacement shader in the video) and having this standard is still worth it, since you can very easily maintain complex pipelines with it. Also while the xkcd comic is funny, I don't like it that much as actual advice. Yes, it means that there is another standard, but that by itself means nothing. How useful a standard is, is not defined by how many standards there are, but how many people support that standard. If many tool developers are all using their own standard or are unhappy with existing ones, collectively creating a new one is the only logical choice.
The main win for everyone (except weirdos who thought that proprietary .DOC format was better or something) is that all those files just ZIP with XML inside. It's trivial to open and parse. They are full of garbage and very strange metadata about your computer though, so be carefull about privacy and don't send those files in default configuration thinking you're anonymous.
@@rogo7330 DOC wasn't even that bad. PDF is what really blows my mind. It hasn't made sense to use PDF as a sharable document format in almost two decades, yet it's STILL the standard document format on the web. It does everything wrong, literally everything, for sharing and collaborating over the web. Wrapped HTML is a better file format. Sure, if you're sending a document off to a publisher that is meant to be turned into a book or something, ok, use a PDF, but why the F would you share your grandmother's chicken pot pie recipe as a PDF?
Been making a USD pipeline for our Digital Twin projects (think of it as game/simulator for companies), taking in CAD data from SolidWorks, piping it to Omniverse, that generates the USD files, with assemblies and subassemblies neatly seperated as seperate files and referenced in the main assembly. Afterwards, we would have a data prep stage, where we'd append metadata, mark anything we could merge, move or delete. Finally export from Omniverse to Unreal, where we convert any marked parts of the hierarchy to be replaced with our blueprints. Most of this is still being worked on, but USD is really great for transfering a lot of important data between programs, which you can build tooling around.
Apparently the reason why they haven't implemented USD support already is because the USD format is huge, which is why they'd prefer to implement it as a plugin rather than built-in.
Working on a game engine in Odin, but it's in the early architectural decisions phase. USD support sounds like a pretty excellent item for the project board.
Acerola is a lifelong Persona 3 fan, the Color Your Night from Reload at the very end was a pleasant surprise Interesting video as always, love learning this kind of stuff about graphics, the one that's as comprehandable as possible
you had me at "the material data, which is the instantiation of a shader, which also encapsulates texture references and arbitrary shader uniform data" very detailed and interesting video, thank you! great to learn about USD
If the bounding box given in the usd file is used to cull objects, and the bounding box encloses the plane before the heightmap shader, then what happens when you orient the camera so that you're looking at the top of a mountain? Does it dissappear? Do you have to account for the future heightmap when defining the bounding box in the file?
This is a great video and I'm really glad USD is steadily getting more of a spotlight. There is a ton of really exciting aspects to USD that I think deserve more of a spotlight though if you decide to do a follow up in the future. For example: variant sets, layers and contextual activation through runtime variable expressions are all immensely powerful
@@24wherath36I did a quick search through the (150 page+) RFC and couldn't find reference to neural networks. I think they are optional in the reference implementation to handle switching between the encoder modes and packet loss, but not strictly essential?
@@rogo7330 true, but its "universality" is not really set in stone, every software supports it in a slightly different way, resulting in files that often just dont work right in other DCCs unless custom pipeline tools are used for import/export, which means a possibly slower workflow for a one-man studio AND it working correctly in a single software only. Not to mention the lack of rig support, the lackluster materials implementation in most software (check out materialx as well) and the multiple possible workflows and composition arcs that can break extremely easily if not fully supported everywhere. There is still a long way to go, but I am looking forward to it.
Yeah, I wouldn't really expect a newer standard to have great support out of the gate. Eventually information on how to do USD right should make it's way around and some useful tools for indie devs will emerge if investment continues at the large org level. In particular for individual devs, USD could really improve workflows around porting from one engine to another. That would already be very exciting, even if things need to be fixed after being imported.
8:02, actually its a list of tuples, python arrays dont use [], and you have to import a specific library to use them, small detail, but i thought i should note it.
Eh, "list" is basically python's name for arrays. Even though it also has something different that it calls "array", but i don't know what the difference is because i don't think i've ever used it 🤷♂️ Do arrays only contain one data type?
@@volbla lists are very different from array, for starters they only contain one data type, and they have a fixed lenght that cannot be changed after it was initialized.
@@ethanbuttazzi2602 Ok, you're right. But in this example there is no practical difference, so i think few people will care about the technical difference.
@@Acerola_tYou sort of already can do this in Nvidia Insight. There is an option to generate/export a C++ file and all binary data (shaders, textures) for that frame.
OpenUSD is heavyweight. Gltf is lightweigth. Gltf is prefered for the web for example. I think openUSD is better used for whole movie production, or other things of this scale.
USD is philosophy* of CG file organization that happens to use .usd as a file format. GLTB/GLTF is an alternative file format for CG workflows. USD can have fbx, obj, glbtf as fileformats.They can just be organised better using USD workflows.
Ok so I've built my own raytraced renderer, for which I implemented gltf for scene import. The standard is old and outdated, only barely functioning via extensions. It's material support is extremely poor and frustrating. It is also NOT a scene descriptor, it is an OBJECT descriptor, thus it has no support for environment maps and other useful scene metadata. I spent more time working around it's ridiculous flaws than it would have taken me to implement USD compatability. Terrible standard, avoid it like the plague.
It's crazy how much my music taste overlaps with my absolute favorite youtubers. Acerola here with the Mother Mother shirt, Technology Connections reps TMBG merch a bunch, all is right in the world.
Acerola: OpenUSD has been a standard for the past 8 years and everyone uses it Unity: USD Experimental Package for Unity Yeeeep that's classic Unity for ya
When I was 16 I did work experience for a week at a company that did CAD and I started to write a program in the version of basic that ran on some model of (even at the time) increasingly obsolete minicomputer that now escapes me to translate their files into Pixar Renderman format to move them to the (comparably powerful) Macs they were looking to move to.
_One of the key differences between GLTF and USD is the intended use case. GLTF is often used for web-based applications and lightweight 3D models, while USD is designed for complex and high-fidelity 3D scenes used in film, animation, and visual effects._ _Another difference lies in their feature set. While GLTF is capable of representing basic 3D models with textures and animations, USD offers more advanced features such as instancing, variant sets, and layering, making it suitable for handling large and sophisticated scenes with multiple collaborators._ It sounds like gltf is supposed to display individual and finished models, whereas usd is supposed to translate between different softwares inside a production studio. So gltf is an export format and usd is a production format?
I think there is a mistake at 7:18. In the right-handed z-up coordinate system, x would be increasing towards the viewer and y would increase to the right. Alternatively, if you orient x to increase to the right, y would be increasing away from the viewer.
Thank you very much for this video! I've got a friend who's really into low poly stuff and I really like procedural stuff, so that's going to be a good few weeks of fun!
"USD currently cannot describe rigs" excuse me what? you sure about that? skeletal meshes with "bone-transformations" are not in this exchange format supported by the entire VFX/Games industry? I would be really surprised
I'm not sure exactly what Acerola means when he says this, but what I've found is there is a module for describing rigs (UsdSkel), but it doesn't allow for any complex behaviors or anything like that. The UsdSkel documentation specifically says it's not intended for general rigging. So basically you could share the skeleton itself in a model, but not any of the rigging behaviors you would want to describe.
you can describe basic skinning weights to a skeleton like just like fbx, but not complex rigs with various deformation methods / blendshape / how they are connected to control shapes etc
@@Luijeee if you were to use USD for the scene, is there a way for it to reference an external file for that information? And is there any open source format that sufficiently covers such things for rigs?
@@blarghblargh in film production where characters aren’t just deformed by classical rigs but likely have simulated hair, cloth, and muscles/tissue you would use vertex cache animation at the layout stage anyways - changing animation would mean a round trip back to your animation pipeline. I imagine USD’s layering feature would allow the animators to easily load the current environment part of the scene into their animation scene for reference if they want to. Even FBX doesn’t enable full character exchange after a certain complexity. FBX style characters with rigs are more relevant to game devs, so I guess it is not high on Pixar’s list.
@@InsaneAudioMediaJunk sure I can understand why film companies would have different priorities than game devs, because they have multiple orders of magnitude more novel animation, and need to better support those use cases. Plus they've put in hundreds of thousands of hours into their custom tooling, if not millions. I just do game dev, so that isn't exactly why I'm asking or what I'm asking about though. I have only done basic skinned animation, ragdoll rigging, and hacky simple blend shapes based on diffs of models. I haven't worked with hair, clothing, or other secondary animation like bouncing satchels or jiggle physics (except for some simple custom scripted IK stuff on tagged bones). So I am curious what there even is in games, beyond simple cases, that I haven't thought about, and what is supported by generic formats (or even open source formats) and doesn't require going to some sort of custom solution (even just to annotate).
I’ve akshchually heard about it, and written converters to/from internal formats in C++! The PXR library is the goat, but in “corporate” situation, their “library loaders” kinda suck, so feel free to ask questions!
this is really cool to see you talk about. i already use usd heavily in my 3d work as i'm primarily using houdini to make animations and it's been a really cool (albeit a bit confusing at first) process to learn and understand all its benefits. another interesting piece of this puzzle is MaterialX which is becoming increasingly standard for material definition. I'm not sure how relevant this is for games stuff but if it is it would be cool to hear your take on it.
![The moment we stopped understanding AI [AlexNet]](/img/n.gif)
To try everything Brilliant has to offer for free for a full 30 days, visit brilliant.org/Acerola/ you’ll also get 20% off an annual premium subscription! #ad
I got covid at siggraph so unfortunately I didn't have much time to create a cooler demo for you all making use of USD, but I hope you all like it! Be sure to speak up about a Godot integration if that interests you. Next video I'll be back on my goat stuff.
All I know is I hope Acerola earns lots of USD.
cat :)
Putting the cat in the ad was a stroke of pure genius
My colleagues would for sure be interested. So far I’ve found Unreal integration much less cumbersome than Unity and in my practice which is to work with small teams (less than 10) with variable levels of skills, implementing USD into production still isn’t really the thing. Even Remedy, who did a whole assed integration of USD for Northlight, are still progressively migrating from the good ol’ FBX pipeline. USD also introduces the problem of version control for the artists and it’s been the thing that has terrified all my colleagues who already struggle at the idea of merging a branch.
So the overhead cost of educating your team and also make sure they can’t break stuff and that they understand the pipeline to fit in there really isn’t very practical, especially that the tools are new, unstable, and miss pretty big features such as rigging. The part I’m most interested in is the interoperability between the engine and the creation tool, aka you move a statue somewhere and the artist can work on it, moved, in their own program. Convenient. But great powers great responsibility etc.
Since there isn’t a Houdini Engine for Godot, USD surely has some more extra attractiveness to it I think. However, Blender’s integration of USD also totally sucks and they don’t seem to want to make it anything else but a file format since Blender’s formatting is pretty antagonist to the logic implement in USD. So this is a big obstacle for the Godot integration since most of Godot users also are Blender users, for the sake of open source free programs.
Before finally quitting school because I got a job instead, I wanted to make my dissertation about USD and quickly landed into the interoperability and version control problem. Without full interoperability and full version control (the API allows you to build one but it’s not that easy), it has little appeal over just doing as we always did: export the FBX and get the axis, the handedness and the scale wrong.
But Acerola
"there were 17 formats."
someone: "we should make a new, universal format that can use everything."
"there were 18 forma-- oh wait, people are actually using it universally? well damn."
That's what happens generally when that someone is Pixar
or Google (webp & avif)
there are 3 "universal" formats(obj, gltf, USD) and a bunch of widely supported formats, so comic still stands
and Godot and three.js have the best gltf support out there
This is xkcd 927
It's better than perfect, it's standardized!
Technology Connections reference? :O
Unironically yes. Can you imagine having to support 30 different "perfect" standards? Because I don't have to, and now I'm losing all my hair.
@@theexaustedslime That's the norm for most software engineering jobs
But USD uses std and other compiler specific primitives in its C++ API, so it locks a user to a specific compiler, and not just compiler but a compiler version -- one can't use their DLL/LIB, as the ABI won't be compatible. So, a user must compile the whole USD locally for the specific compiler / version. Good luck debugging sporadic crashes (because of ABI incompatibility) if someone forgets to push right lib/dll 🙂
@@sultim7570 Software is the gift that keeps on giving. A wellspring of infinite work!
Apple embracing PIXAR's creation as a standard is surprising, until you remember it's PIXAR. You tried, Apple.
apple embracing any standard is already surprising
@@davidzaydullinyeah they usually help create them like usbc and thunderbolt
@@chidorirasenganz yeah and then refuse to use or implement it for years and years! What geniuses! And if they make it a closed standard then they can gatekeep it too for MAXIMUM PROFIT!!!!
@@davidzaydullinuntil they are forcee, like the eu 💯
Steve Jobs owned a significant portion of Pixar
I feel like this is, if anything, underselling what USD can do. From USD files potentially being human readable and editable, to the ability to use hydra to plug a USD scene directly into most render engines, to the ability to layer USD scenes across multiple files, editable across multiple users and different software in parallel, it is an absolute beast. And that's just the benefits I've noticed as an artist with zero pipeline or coding experience.
It was a magical moment the first time someone opened a USD ascii file in front of me and created a basic PBR material by just typing the values into notepad.
Agreed, programmatically creating a mesh by specifying vertices and triangles is possible with something as ancient as the obj format
That sounds like black magic to me. Incredible
Transitioning to an ad with the cat on the side, is one heck of a technique for an engagement trap
fr, i think this is the first time i've seen someone do smth like that
it worked, im engaged
He's channeling Louis Rossman.
I thought the cat was "Brilliant" hey what's in a name?
Not to be rude but I personally dislike cats so I always skip it 🙃
watching this as someone who makes vrc assets
wait why aren't we using .usd everywhere?
"usd currently cannot describe rigs"
..ah that's why
Pixar did this intentionally - USD is one half of their file pipeline. The other half, for rigging and animation, is kept closely internal.
Yeah, but USDZ (USD) is supporting skeletal animation.
I suppose you can still use it for worlds at least
workaround:
just do a .usd file for every frame and you can make animations
maybe its done before you die
@@mugnuz Why do people keep saying that USD doesn't support skeleton animation? It does, and I've been creating animated USDZ characters for years.
"If it finishes before you die then it's fine"
Is a mantra fitting for Python programming
Python isn't fast, but if it's that slow, you're just a bad python programmer. I find it hilarious that one of main mantras of python is "there should be only one way to do things", but everything in python can actually be done 9 different ways, 8 of them are obvious and slow as f, and one is obscure, but fast(er)
@@gorak9000python is slower than everything else
@@gorak9000 you make python fast, by cheating*!
*cheating by just offloading the actual computation part to C code, and using CFFI to import the result back to python-land
From what I have read, there are now compilers for Python, giving a nice speed boost. I don't know about compatibility though.
@@javabeanz8549 hmm, I looked it up, seems it's called codon, and it looks pretty sweet! Thanks for that!
Alan Wake 2 (well NorthLight) used USD files for their entire game. It allowed them to do live editing from Maya, to the editor, to the game. They put out a few videos when Alan Wake 2 launched about the new features to their engine
Can you link the videos? I’m invested now
@@Hecktic117not sure what is up with TH-cam, I tried twice to post the link. Go to remedy games’s website and click on Northlight Engine, that has most of the videos on various blog posts
I'm not a 3D dev, but seeing open-source standardization like this is really exciting. Much love to the talented people working to make development more accessible, universal, and user-friendly!
Actually not knowing something when a video is titled "X You've never heard of" is the death of my ego. 99% of the time it's clickbait where they're just talking about something everyone knows of and I get to be a smug prick about it.
at least you get to know!
It being something new is the dream scenario.
In this case I thought, "Isn't that just USD? That's not so obscure…" before clicking the video.
And sadly I was right, no new knowledge for me~
uhm ackshually 🤓 the api is in c++ with python bindings
You could theoretically write bindings quite easily for any language with C++ interop (Zig, Swift, Nim, Rust).
@@mduardo D
@@andrewlalis F#
@@bosch5303c#
Python is based in c/cpp so it's all cpp until proven otherwise
I fucking love it when he goes "But Acerola..!"
I miss the accompanying drooling cartoon depiction of his audience :D
that guy wasn't drooling he was getting sloppy toppy i'm afraid
@@Acerola_t even better
But Acerola,,, that kills people!
@@Acerola_tAfraid of what? Do not be scared.
The strategy to keep us entertained on the sponsor segment with your cat worked on me, get your free ad money
FFS, indeed; that was brilliant.
Wait...
I mean... the money ain't FREE, it's compensation for services rendered. It'd only be free ad money if they got paid despite never showing an ad.
@@PotatoPatatoVonSpudsworthok
@@egonzalez4294😂
7:20 A small correction: right-handed and left-handed coordinates are actually the opposite of what's shown in this video. Handedness isn't about what axis points up but about the relationship between the axes.
It confused me when he said that unity uses left handed coordinates, because that would make so many calculations wrong.
I paused the video and fiddled with my fingers for a couple minutes before concluding that my hands are on backwards
0:50 _gasp_ Apple and Nvidia working *together* on something?!?!
Haven’t seen this since High Sierra!
You’re probably still waiting for NVIDIA Web Drivers for Mojave :D
@@veemyu Some madman got them working on Monterey. It’s insane.
@@TR4NS1ST0ROCLP root patching can get you webdrivers on Sonoma, however the lack of Metal support is mid
@@veemyumojave was such a legendary version for macos
GLTF came out 8 years ago and we thought it would be the universal standard. Pixar released USD and seemingly everyone jumped on the hype train and forgot about GLTF and now there's 2 competing standards
we should make another, newer, more complete standard that combines the two
@@turquoise7817 One that cover everyone's use cases! #xkcd
@@turquoise7817 Situation: There are 3 competing standards
Never heard of it
They're really not that comparable. GLTF is more of a transmission format while OpenUSD is more of an interoperability format that targets large-scale entire scene data in a way that makes collaborative editing easier. A comparison I've seen a lot of is OpenUSD is to PSD as GLTF is to JPEG/PNG, you likely wouldn't ship the product using OpenUSD, but OpenUSD contains a lot more functionality and data than GLTF and thus has added value during the creation of the product.
GLTF has it's advantage in the realtime rendering and loading aspect of a game, while OpenUSD has it's main value in the production pipeline, while both represent collections of objects and data, that serve different purposes. It wouldn't be uncommon to see people develop a game in OpenUSD, then convert to GLTF for distribution.
7:14 correction: in a z-up right handed coordinate system, y points away from the viewer. take your right hand, point your thumb (x) to the right and your pointer finger (y) away from you, and you'll see that your middle finger (z) points up. In Unitys left handed y up coordinate system, z points away from the viewer.
Alternatively you can think of the index finger as X, the middle finger as Y, and the thumb as Z (I personally prefer it this way)
🤓
I came to the comments to say this as well
100% engineer/physics pilled moment. I immediately raised my right hand when i saw that shit and was like "whaa?"
Studying physics in uni we were dissuaded from the classic right hand rule and encouraged to use the thumb rule instead (which still depends on which hand you use... but the convention is right). If you curl your fingers from the first axis towards the second axis, your thumb will point in the direction of the third axis.
Maybe this is just habit, but i've come to feel this is easier to remember. Instead of making your hand into a strange shape, it's like you're just grabbing the z-axis and utilizing the natural directions of your fingers.
But Buffrola, how do I get them gains?
I'm sorry
just go to the gym and eat food it was surprisingly that simple
glad i am not the only one that thought that, nice gains :)
Veggies for dinner(always, to enter intermittent fasting and get rid of stubborn fat), protein based lunch and breakfast(meat, eggs, little of fish), cut carbs to a minimum(if you want to eat a pizza a week, go ahead reward yourself).
For volume max 9+- reps; for stamina, strength and "leaniness" go fo 15+-; dont mix them in a fast pace, one week one and the next week the other. Surprisingly doing various sets doesnt do much, the one that gives more its the first one, its better be consistent than giving up so you can start at the first reps and adapt to it(dont go overboard, or youll give up by your own expectations).
Good luck!
What if the gains I want are not the buff kind?
Ace-swole-a?
Since you're a shader guy, I would appreciate a followup video where you show how to author a shader and it's material instances entirely inside USD, and then have it appear in Unity or Unreal or wherever.
IMO using mesh generation as an example application of USD really misses the mark and undersells it. 20 years ago I wrote code to generate OBJ files procedurally, because OBJ is a really easy format to generate to store verts, faces, normals, etc.
In my mind, the powerful thing about USD is the non-geometry features, so I would like to see you cover it from that perspective.
20 years ago I was outputting POV-Ray source code. :-)
YT recommended this video and I instantly clicked because of the title. As soon as I started watching the video I went, "Isn't that the grass guy?" from your video about how games render so much grass from 2 years ago lol. I guess you are just super unforgettable. Nice video btw.
My brain is weird. When you said "per vertex data", my brain refused to hear anything other than "pervert ex-data".
I read your comment at just the right moment as he said that.
Thanks, I will never be able to unhear that now
@@banaia5455😂
Hold up. They have a physics API but can't describe rigs yet? :/
that's cause the physics api is way simpler than a standardized rig description
Yes the physics API is super super simple. You are basically just annotating objects with the bare minimum number of properties needed for rigid body physics. So collider shapes, mass, etc.
Also USD does not provide a specification or handle the actual physics simulation. I.e. there is no physics engine. Thats on the developer to implement in their software that is consuming the USD.
@Acerola_t for real though, trying to export/import rigs from an older game for modding made me hate every single general purpose 3d model/rig file format that exists
@@TheCrewExpendable Thanks! I was wondering how that "it supports physics" worked. So it supports describing initial conditions, not running the simulation.
Naw this is a deal breaker. FBX exports and mesh gen scripts in random software remains superior
I've been doing game dev 10+ years ago, never heard of USD until I worked with it at Microsoft 3 years ago. After that, I've seen it everywhere.
14:48 Interesting, I remember you talking about Godot not really having the support for the graphics-heavy stuff you want to do a while back. Has something changed in that regard?
yeah unity continues to nose dive at every single turn and godot only keeps accelerating -- I want to provide value to my community, and I don't think that's with unity anymore
My experience clicking on this video was something like this:
“Ah finally my VFX degree comes in use, they must be talking about FBX”
“OpenUSD”
“Ah, bollocks”
Acerola about to make massive USD from getting me to watch the entire ad. Brilliant move 😎
I think you got the handedness wrong at 7:13, that's not how my right hand works
yeah they definitely either got their handedness backwards or mixed up the “into” vs “out of” the screen description.
Came here to see this or say this. Right handed +Z up is +Y away. Coord frames are hard.
4:30 having a cat video play during a sponsor segment is so effective. NighHawkInLight also does something similar (plays with his parrot)
Yeah, that's the first example I saw of this technique. It's a very clever trick that works without making the ads more obtrusive. And since that makes this an objectively better way to do advertising, clearly the entire ad industry should be moving to this new cute animal standard.
Super smart and ❤
Man, when Junes theme is playing there, i got instantly hooked up 😄
The cat in the ad always works
The man is a genius
he found the trick to make us sit through his little punk ass ad
He's channeling Louis Rossmann.
worked on me
I normally don't watch advertisements, but the kitty cam tricked me into watching through the whole thing.
0:14 he says unify yet shows an intersection. who are you, really, acerola?
hes into graphics stuff...
its all about perspective!
from one view its an intersection.
from the other side its a funnel! ;D
2:40 Funny thing about this. OpenUSD doesn't support rigs because, actually, no software has ever supported rigs. So this is still a universal ideal.
what? glTF supports rigging, meshes, textures, scenes, and a whole lot more
Funny coincidence, as Godot just recently released 4.3 update featuring improved FBX support instead. Understandably so, since rigging is very important
Skeletal meshes are supported in USD by the way, just like they are in FBX. I think the missing rig definition he is talking about is the actual whole rig with controls and deformers. This means you can bake your animation on the skeleton in maya and export it wherever you want, but not export the whole rig from Maya and animate it wherever you want
@@sirdiff1 That was my reading too. The UsdSkel documentation even says it is not a general rigging format, and it sounds like it never will be.
3 shader formats for the rendering kings under the sky
7 texture formats for the sculpting lords in their halls of tablets
9 model formats for outdated engines doomed to die
One format for the dark animatiors on their dark chairs
In the land of pixar where the shadows lie
One format to rule them all, one format to find them
One format to bring them all, and in the darkness bind them
In the land of pixar where the shadows lie
Would love Godot support, sounds pretty nice
That’s on Godot to implement I think
It's on the community. If someone implements it, it will get implemented.
Your videos really keep coming around at the perfect time for me! I'm building a 3D "Engine" ontop GameMaker Studio 1.4 and have just finished my PBR shader. I found myself writing a custom set of scripts to delineate surface material values, and every time I re-invent the wheel like this I ask myself: "How is everyone ELSE doing this?" Sometimes It's actually a bit comforting to know that -up until recently- everyone was just ramshackling their own solutions together just like I did.
Working with Game Maker Studio 1.4? Impressive. I think someone did make a 3D engine in the past, know it's a lot of work so good luck for you there!
I would love to see this for Godot.
Just use GLTF like we did for years now
There's a push for it, and I think some people are poking at it. GLtf does most of the same more efficiently, and on roughly the same standards, though, so I'm not too worried about it.
Assemble the nerds and it'll happen.
@@PySnekdifferent use case. USD will be more of a replacement to the Godot scenes. Ofcourse you CAN uae gltf for scene authoring, but USD fits the purpose much better.
@@askeladden450 Than just update FLtf to cover scenes instead of putting so much effort in a new standard... I just don't get it and it's always the same story.
And to think the Amiga had IFF interchangeable file format back in the 90s. Not a 3D format, but an example of having universal formats.
IFF, the “Interchange File Format” standard, encourages multimedia interchange between different programs and different computers. It supports long-lived, extensible data. It’s great for composite files like a page layout file that includes photos, an animation file that includes music, and a library of sound effects.
2:15 I can't be the only one to hear it.
🤣
thanks I hate it
Yeehaw!
Can i just say how much i respect you for finding a way to keep nyself entertained during a ad. The cat video really made me go through the whole ad.
dude acerola moving to godot would make me soooooooooooo pogged out my gourd
Putting a cat video side by side in the sponsor section is such a great idea
2.5 years of python and OpenUSD and this is hands down the best explanation I’ve seen
Is fun to see how a field that started in the early early days of the internet diverged so much that integration/standardization is only lately been adopted. There are some other fields were integration came right away. Is fascinating to see. Lovely work.
I hate it when developers get annoyed at people calling something a "file format" when there is no a better word available and when it essentially _functions_ like a file format as far as the end user is concerned.
Your channel is awesome!
I've been everything from a jr gameplay programmer up to senior tech artist at FAANG and still find your content always has things to learn for every skill level, and its also lots of fun.
Now I just need to get the rest of the 3D world on my Quaternions > Matrices hype train as the core approach to rotations in modern engines...
Why do you like quaternions?
Since you specifically pointing out about ".append()" in the python code, you can use ".extend()" to append multiple values at once on 1 line.
I see that the standard has various extension mechanisms. Probably necessary, given the functional impossibility of covering everyone's use case; but the sort of thing that makes you a trifle nervous about interoperability in practice.
Are the tools that support the standard pretty good about sticking to a well-formed core of mutual understanding; or do you run into a pretty significant risk of finding opaque vendor blobs that are 'standard' in the sense that they obey the standard's specifications for embedding and talking about arbitrary blobs; but more or less profoundly unhelpful if you are trying to interact with output from certain tools; or move between tools with their own opinions on vendor specific formats?
I'm think of the (admittedly much more beige and blandly corporate) instance of when office documents largely went from the old binary formats to the new-hotness 'open' it's-just-a-zip-file-with-XML-isn't-that-great; but documents that were nothing but a bunch of OLE blobs that couldn't even be moved between computers with different OLE handlers; much less cross-platform, were technically 'open' so long as the XML telling you that the thing was just rammed full of blobs was well formed); or the...unfortunate...discrepancies you can run into between PDF as in ISO 19005 and 'PDF' as in whatever Acrobat feels entitled to emit.
it's all diff representations of the same data, .usd is raw, .usda is an ascii representation so you can write it like html, and .usdz is a zip
@@Acerola_ttechnically .usdc is the binary format ("crate") and .usd can contain any .usdX format (usually usdc)
This is very interesting, but I also am wondering, how about collaborative editing? something like git for 3d modelling? something like that must exist in major companies like Pixar because I don't know how they are working together on the same scenes
There's one guy modelling one asset. Juniors will model simpler stuff like props and seniors usually work on hero assets like characters and what not. The layout/lighters can easily import those models after and create a scene based on the descriptions.
Interesting, so that means there is also one guy on the scene itself? Or is that something that is shareable? (Technically you can use git here with the usd format i guess so that might be it)
Collaboration is made easier with the possibility to cut the scene in multiple files a lot of way.
One of the aim of the nvidia omniverse platform is facilitating a git-like behaviour with a file server enabling file history and reference to older versions of the file. It also has live editing capabilities directly on the same scene, that I don't think are standards but are quite open via quite a few of extensions bringing them in other tools
7:20 that's the left hand coordinate system you're describing.
Curl your left or right hand with the thumb sticking out, as if you were giving a thumbs up👍 to someone. The four curled fingers show the shorter directed angle from OX to OY half-axis, and the thumb points to where the OZ half-axis should be. If it's the right handed coordinate system, then the right hand will show the OZ half-axis, if it's the left handed coordinate system, then the left hand will show the OZ half-axis
Oh what a Monday to start off with an Acerola video on an extremely niche topic I've never heard before!
This video was enjoyable and informational
Never knew this existed till now
Well done you have earned my subscribe
I'm glad that this is a thing in this world where so many programs have their own file format...
Glad there I something uniting them all, and hopefully soon this will be standard in every program
Thank you for making this video and telling the world about OpenUSD
Have a Great Day Acerola, and I can't wait to see what you make next 🖖
I feel like reading the XKCD cartoon about adding one more universal format to end all formats!
I think innovation is too dynamic and CGI too complex for all use cases to be compatible with a single data format.
It can only be like Word vs Libre Office Write files. Roughly compatible, but tons of small implementation differences and some data that doesn't fit and is lost.
It doesn't have to cover all possible usecases though. Simply providing a format that covers most basic concepts and is understood by all programs is already incredibly useful. You can still have program-specific usecases (like the displacement shader in the video) and having this standard is still worth it, since you can very easily maintain complex pipelines with it.
Also while the xkcd comic is funny, I don't like it that much as actual advice. Yes, it means that there is another standard, but that by itself means nothing. How useful a standard is, is not defined by how many standards there are, but how many people support that standard. If many tool developers are all using their own standard or are unhappy with existing ones, collectively creating a new one is the only logical choice.
The main win for everyone (except weirdos who thought that proprietary .DOC format was better or something) is that all those files just ZIP with XML inside. It's trivial to open and parse. They are full of garbage and very strange metadata about your computer though, so be carefull about privacy and don't send those files in default configuration thinking you're anonymous.
@@rogo7330 The DOC format *was* better when you're saving files to floppies and such.
@@rogo7330 DOC wasn't even that bad. PDF is what really blows my mind. It hasn't made sense to use PDF as a sharable document format in almost two decades, yet it's STILL the standard document format on the web. It does everything wrong, literally everything, for sharing and collaborating over the web. Wrapped HTML is a better file format. Sure, if you're sending a document off to a publisher that is meant to be turned into a book or something, ok, use a PDF, but why the F would you share your grandmother's chicken pot pie recipe as a PDF?
This is the first brilliant ad that I didn't skip. Your cat is the best.
Wisdom is knowing what to do next; Skill is knowing how ot do it, and Virtue is doing it.
Just as a note, that's an amazing way to get people to keep the video up during the sponsored segment.
Idk if you have been getting this a lot but you have been getting JACKED over the past couple of videos, keep it up!
I knew I wasn’t the only one to notice, good job mr Rola!
He is getting tessellated.
It’s a height displacement map.
I am so happy your channel got recommend to me. Keep doing what your doing this is so great!
The vertices of bros biceps have been displaced along their normals.
Been making a USD pipeline for our Digital Twin projects (think of it as game/simulator for companies), taking in CAD data from SolidWorks, piping it to Omniverse, that generates the USD files, with assemblies and subassemblies neatly seperated as seperate files and referenced in the main assembly.
Afterwards, we would have a data prep stage, where we'd append metadata, mark anything we could merge, move or delete.
Finally export from Omniverse to Unreal, where we convert any marked parts of the hierarchy to be replaced with our blueprints.
Most of this is still being worked on, but USD is really great for transfering a lot of important data between programs, which you can build tooling around.
Apparently the reason why they haven't implemented USD support already is because the USD format is huge, which is why they'd prefer to implement it as a plugin rather than built-in.
Working on a game engine in Odin, but it's in the early architectural decisions phase. USD support sounds like a pretty excellent item for the project board.
USD - Check
Let's wait for Open-EXR, OpencolorIO, etc 😉
Many thanks for your educationnal standard which is a grace and a pleasure to watch.
Acerola is a lifelong Persona 3 fan, the Color Your Night from Reload at the very end was a pleasant surprise
Interesting video as always, love learning this kind of stuff about graphics, the one that's as comprehandable as possible
Imagine instead of getting a screenshot, you get a baked, barely reusable openusd file.
It would be a really neat gimmick
you had me at "the material data, which is the instantiation of a shader, which also encapsulates texture references and arbitrary shader uniform data"
very detailed and interesting video, thank you! great to learn about USD
If the bounding box given in the usd file is used to cull objects, and the bounding box encloses the plane before the heightmap shader, then what happens when you orient the camera so that you're looking at the top of a mountain? Does it dissappear? Do you have to account for the future heightmap when defining the bounding box in the file?
Working with USD in Houdini Solaris is absolutely top tier. It's like a control panel for your entire CG pipeline
2:15 missed opportunity
Pervert ex data
This is a great video and I'm really glad USD is steadily getting more of a spotlight.
There is a ton of really exciting aspects to USD that I think deserve more of a spotlight though if you decide to do a follow up in the future.
For example: variant sets, layers and contextual activation through runtime variable expressions are all immensely powerful
1:20 oouhhhgggggmmmmm girl🤤🤤🤤🤤🤤🤤🤤🤤🤤🤤🤤🤤🤤🤤🤤🤤
"an exact copy"
I am staring at the rotated triangulation edge judgingly
but acerola,
lol 37
I'll save this video, I'm majoring engineering in geophysics and this seems to be useful. Great job as always Acerola ❤
Wake up babe new acerola video
Dude I'm tired of the 'wake up babe' TH-cam comment meta, can we move to the next one already?
@@Grimnoire WE MOVING TO THE NEXT ONE ALREADY WITH THIS ONE❗‼️🗣️🗣️🗣️🔥🔥🔥💥💥
BUT ACEROLA-
Turn on the tv, doesn't matter what channel
@@metaphysical_anachronism ah yeah, that's better thank you.
Hey dude, this was randomly shown on my pipeline and I love the Mother Mother shirt! My wife and I jam out the Hayloft I/II all the time!
I knew it. Opus is the best file format!
It's kinda crazy how efficient Opus is
@@AnimeUniverseDE It's also kinda crazy how complicated it is as well. It literally has multiple neural networks build INTO the format.
isn't opus an audio format? (I'm not a 3d artist)
@@rvft yes
@@24wherath36I did a quick search through the (150 page+) RFC and couldn't find reference to neural networks.
I think they are optional in the reference implementation to handle switching between the encoder modes and packet loss, but not strictly essential?
I appreciate you explaining how the vertecies and tris are encoded, this gets me curious on how UV positions and custom normals are also stored.
No one-man gamedev studio will benefit from USD. It's made for studios and pipeline integration across large organizations.
At least it is not bound to the particullar tool you are using.
@@rogo7330 true, but its "universality" is not really set in stone, every software supports it in a slightly different way, resulting in files that often just dont work right in other DCCs unless custom pipeline tools are used for import/export, which means a possibly slower workflow for a one-man studio AND it working correctly in a single software only. Not to mention the lack of rig support, the lackluster materials implementation in most software (check out materialx as well) and the multiple possible workflows and composition arcs that can break extremely easily if not fully supported everywhere. There is still a long way to go, but I am looking forward to it.
Yeah, I wouldn't really expect a newer standard to have great support out of the gate. Eventually information on how to do USD right should make it's way around and some useful tools for indie devs will emerge if investment continues at the large org level.
In particular for individual devs, USD could really improve workflows around porting from one engine to another. That would already be very exciting, even if things need to be fixed after being imported.
I had expected it to be EXR based on the title, but also thought maybe USD. Great overview with examples. Also thank you for never saying “softwares”.
8:02, actually its a list of tuples, python arrays dont use [], and you have to import a specific library to use them, small detail, but i thought i should note it.
Eh, "list" is basically python's name for arrays. Even though it also has something different that it calls "array", but i don't know what the difference is because i don't think i've ever used it 🤷♂️
Do arrays only contain one data type?
@@volbla lists are very different from array, for starters they only contain one data type, and they have a fixed lenght that cannot be changed after it was initialized.
@@ethanbuttazzi2602 Ok, you're right. But in this example there is no practical difference, so i think few people will care about the technical difference.
@@volbla thats why i said little detail.
@@ethanbuttazzi2602 Fair :]
Bro has god tier advertisement skills.
So wait it would be super cool for it to be used to export 3D screenshots of a game.... especially for emulators.
Even attempting to do that is nothing but daunting.
that's effectively what a frame capture is, I wonder if nvidia nsight is lookin to do that
@@Acerola_tYou sort of already can do this in Nvidia Insight. There is an option to generate/export a C++ file and all binary data (shaders, textures) for that frame.
Laughs in render doc …
Not gonna lie, your intro/title screen animation style is probably the cleanest I've ever seen.
Why is openUsd better than lets say gltf?
OpenUSD is heavyweight. Gltf is lightweigth. Gltf is prefered for the web for example. I think openUSD is better used for whole movie production, or other things of this scale.
USD is philosophy* of CG file organization that happens to use .usd as a file format. GLTB/GLTF is an alternative file format for CG workflows. USD can have fbx, obj, glbtf as fileformats.They can just be organised better using USD workflows.
Ok so I've built my own raytraced renderer, for which I implemented gltf for scene import.
The standard is old and outdated, only barely functioning via extensions. It's material support is extremely poor and frustrating. It is also NOT a scene descriptor, it is an OBJECT descriptor, thus it has no support for environment maps and other useful scene metadata.
I spent more time working around it's ridiculous flaws than it would have taken me to implement USD compatability. Terrible standard, avoid it like the plague.
@@Selsato GLTF1 or 2?
@@AdamScottPersonnel gltf 2.0
It's crazy how much my music taste overlaps with my absolute favorite youtubers. Acerola here with the Mother Mother shirt, Technology Connections reps TMBG merch a bunch, all is right in the world.
Acerola: OpenUSD has been a standard for the past 8 years and everyone uses it
Unity: USD Experimental Package for Unity
Yeeeep that's classic Unity for ya
When I was 16 I did work experience for a week at a company that did CAD and I started to write a program in the version of basic that ran on some model of (even at the time) increasingly obsolete minicomputer that now escapes me to translate their files into Pixar Renderman format to move them to the (comparably powerful) Macs they were looking to move to.
so, what's wrong with GLTF?
Nvidia. /s
_One of the key differences between GLTF and USD is the intended use case. GLTF is often used for web-based applications and lightweight 3D models, while USD is designed for complex and high-fidelity 3D scenes used in film, animation, and visual effects._
_Another difference lies in their feature set. While GLTF is capable of representing basic 3D models with textures and animations, USD offers more advanced features such as instancing, variant sets, and layering, making it suitable for handling large and sophisticated scenes with multiple collaborators._
It sounds like gltf is supposed to display individual and finished models, whereas usd is supposed to translate between different softwares inside a production studio. So gltf is an export format and usd is a production format?
What is the use of .psd when we have .jpg files?
They solve different problems.
@@Technoyote .psd are lossless layers containing layer effects. A .jpg is the lousy *final composited* image.
I think there is a mistake at 7:18. In the right-handed z-up coordinate system, x would be increasing towards the viewer and y would increase to the right. Alternatively, if you orient x to increase to the right, y would be increasing away from the viewer.
Meanwhile in Unreal: Built-in Modelling Tools 🙏
Thank you very much for this video! I've got a friend who's really into low poly stuff and I really like procedural stuff, so that's going to be a good few weeks of fun!
1:08 WAIT WHAT monogatari editing? *checks name* "ACEROLA???!!! like acerola-orion-heart-under-blade?"
"USD currently cannot describe rigs" excuse me what? you sure about that? skeletal meshes with "bone-transformations" are not in this exchange format supported by the entire VFX/Games industry? I would be really surprised
I'm not sure exactly what Acerola means when he says this, but what I've found is there is a module for describing rigs (UsdSkel), but it doesn't allow for any complex behaviors or anything like that. The UsdSkel documentation specifically says it's not intended for general rigging. So basically you could share the skeleton itself in a model, but not any of the rigging behaviors you would want to describe.
you can describe basic skinning weights to a skeleton like just like fbx, but not complex rigs with various deformation methods / blendshape / how they are connected to control shapes etc
@@Luijeee if you were to use USD for the scene, is there a way for it to reference an external file for that information? And is there any open source format that sufficiently covers such things for rigs?
@@blarghblargh in film production where characters aren’t just deformed by classical rigs but likely have simulated hair, cloth, and muscles/tissue you would use vertex cache animation at the layout stage anyways - changing animation would mean a round trip back to your animation pipeline. I imagine USD’s layering feature would allow the animators to easily load the current environment part of the scene into their animation scene for reference if they want to. Even FBX doesn’t enable full character exchange after a certain complexity. FBX style characters with rigs are more relevant to game devs, so I guess it is not high on Pixar’s list.
@@InsaneAudioMediaJunk sure I can understand why film companies would have different priorities than game devs, because they have multiple orders of magnitude more novel animation, and need to better support those use cases. Plus they've put in hundreds of thousands of hours into their custom tooling, if not millions.
I just do game dev, so that isn't exactly why I'm asking or what I'm asking about though.
I have only done basic skinned animation, ragdoll rigging, and hacky simple blend shapes based on diffs of models. I haven't worked with hair, clothing, or other secondary animation like bouncing satchels or jiggle physics (except for some simple custom scripted IK stuff on tagged bones). So I am curious what there even is in games, beyond simple cases, that I haven't thought about, and what is supported by generic formats (or even open source formats) and doesn't require going to some sort of custom solution (even just to annotate).
great vid, well done. Might try this for procedural terrain in my game dev program this year!
i would never touch python
but im sure there will be libraries for generating it with other languages
As a backend dev I'll never understand how you guys in game dev can create such complex products with such simple code!
I’ve akshchually heard about it, and written converters to/from internal formats in C++! The PXR library is the goat, but in “corporate” situation, their “library loaders” kinda suck, so feel free to ask questions!
this is really cool to see you talk about. i already use usd heavily in my 3d work as i'm primarily using houdini to make animations and it's been a really cool (albeit a bit confusing at first) process to learn and understand all its benefits. another interesting piece of this puzzle is MaterialX which is becoming increasingly standard for material definition. I'm not sure how relevant this is for games stuff but if it is it would be cool to hear your take on it.