 So, good morning everyone, hope you had a nice night and morning this day, Saturday. My name is Tobias, I'm the co-founder of the Blender 3D School and we also host the Blender Day every year. It's a German speaking event in Mannheim and professionally I'm a full stick developer and I also teach software architecture to students at the Corporate State University in Mannheim. Yeah, and as you guess you see is exactly my topic because there's a lot of in for me to understand and to learn about it and today I would like to give you some kind of observations that I made and I will also cover the different pieces of software that is currently available in the Blender universe. Okay, whenever you have some more background knowledge that exceeds my knowledge please just give me a hand. We have a microphone here and you can just share some knowledge so I would like to learn about it also so you are invited to have the talk together with me if you like. Okay with that being said, let's have a look to the outline. I will just give you some motivational slides, the purpose a bit, then we will go over the different software pieces of the USD Blender ecosystem. Beyond that, there is a lot of more that USD is offering and I will try to explain it with Blender terms so maybe it's easier for those of you who are already familiar with Blender internal stuff and how the stage is organized and everything. And then we will have a look how well other DCCs, so DCC is digital content creation software so as Blender, how well other DCCs are playing well with USD so if it's a pain or it's very easy to export stuff using USD to other DCCs. And finally some closing remarks on the future of USD according to my opinion. Okay, please keep in mind USD has been invented for those guys. So you have a large production crew, many departments, many artists in each department they have to talk to each other, they have to share resources, they have to share assets. So whenever you get the impression why is USD doing this and remind yourself this slide because it's not for tiny teams or small teams, it's for the really big ones and the assets somewhere are created and then start their path throughout the whole project team and this is also called an asset pipeline as you can see here. We start as an ideation board, storyboard, we do some kind of block out, we make the modeling and so on and the asset is just moving along the path and those huge teams very easily run into a lot of problems if the pipeline is not setting up very tight and efficiently. And this is where USD has been invented for and Steve May from Pixar once explained that a lot of 3D content has to be moved between different tools and in those departments artists are not only using Blender of course, they also use other DCC so that means throughout the pipeline the asset moves from one DCC to another DCC and so on. And with that we have some challenges. So if artists work on the same project, even on the same file, then you have the problem of the last update wins. If two artists open the same file at the same time and one finish earlier than the other then only the changes from the last one are saved and the changes from the first one are just lost. Then we have different DCCs that need to speak to each other and we have several levels of done in our pipeline assets. They start in the sketching phase, then they are blocked out, then they have been worked up on and then they are released version one, two, three and so forth. And of course we have so many artists and nobody should be blocked because another artist is just claiming the file for himself or herself. So this brings us to the solution to decompose the whole scene into a lot of pieces. And this is what USD is made for, to provide a rich common language for defining and assembling and editing 3D data and to support multiple digital content creation applications. So this is the opening sentence you can read if you go to openusd.org. USD also has some quite interesting features. It allows to edit other artist assets on top of those original asset values without having any loss. So it's very nice to work in a large team. And of course we have a common language, so a common file format for the DCCs that can be shared among the departments. In July 2016, after a huge success of Alembic, which has been made public by Industrial Light and Magic and Sony Pictures, in the year 2011, Pixar released USD as open USD to the public after 20 years of internal development. And with that, they also provided Hydra, I will talk a little bit about Hydra in a couple of slides, and OpenSubtive. And they also provided a reference implementation for Maya and Katana. And just two months ago, the Alliance for Open USD has been founded by some companies and fortunately we have a talk about this today at 2 o'clock hosted by Winsand. So if you are interested in what they are doing, what is their purpose, then join us in the discussion. Just to give you some glimpse why it's important to have some kind of an open USD Alliance. Even if so many different renderers are speaking the same language and importing the asset files, any single one of those renderers has its own opinion how to interpret the lighting values and in some renderers it's very bright, the scene and in others it's very dark. So we need some kind of committee who sets up those standards that were not already defined there. Okay, before we go more into detail I would like to give you the main most important difference between how Blender understands the stage and how USD is structuring the stage. So for example if I want to create a forest scene made up of single trees, I would do it like this. In the last layer I would have my materials, my library file which is just defining the shaders and then I would link those shaders to my asset file where I just have the trees, the mesh data of the trees and then I would have several types and versions and variants of those trees in my trees.blend file. Every rectangle you see here is a blend file and every arc that is connecting those blend files could be interpreted as some kind of referencing linking. And finally on top of everything I have the shot dot blend which is just assembling everything together. So this at least is the stage or the structure of the project I would start with. USD is a little bit different. USD has more pieces. As I mentioned in USD we try to decompose the whole scene in little pieces and we have one USD file here again and rectangle is a USD file it's called layer. And we have one USD file at the bottom which is for example defining the mesh data. Another file is defining the material so this is somehow similar to Blender already. Then we have an object USD file which is referencing the other two files. So it's some kind similar to Blender linking. And then the difference starts because then I have some instances files and those instance files can have overrides. So you can just say okay I will reference to another layer below but I want to change this single property and you can do it it's called over. And in order to do it you have to identify the asset that you want to overwrite and this is done using a naming system. This is identical to Blender the names must be unique and in Blender we have data blocks and in USD we call it prims for primitive. So if you know which prim you want to overwrite you can do it you can just say hey I want to overwrite the prim let's call it tree and then we can add some other colors or some other positions and transforms. And finally we have the shot USD at the top again which just sub layers so integrates and assembles all the other instances that you have in your project. So as you can see here we have more layers we have more blend files USD files they are called layers and this is not only a difference to Blender but I will come to this in a couple of slides. Okay chapter two let's talk about some software pieces that are already available and that you can use. I will talk about the USD importer exporter of course the Hydraadon and the Omniverse Connector. In 2019 Sylvain R. Stüvel makes his first steps into USD and he just tested how well you can export USD from Blender so he was about exporting Blender not already importing it to Blender and he realized even back then there is some kind of different understanding of how the scene is structured and he also had some kind of he made up some very interesting observations for example USD likes to have many different pieces the whole scene is decomposed in many different pieces so that every artist can work independent of other artists on those pieces but in his export everything is in one USD file so this is some kind of a difference and I don't know if this is a technical reason for this but even if you want to decompose the Blender scene into many different pieces you would need how to do it and so this needs some kind of architectural knowledge of the departments and this the exporter cannot have. Another problem that comes with this is supporting instancing if you instance the same asset multiple times in your scene then it would be great that you do not make them real and export them so because then you have a lot of copies of redundant data and USD supports the scheme of references as I said so it would be great to export everything as far as possible as a reference but if you do not have single USD files then it's harder to reference them and this is also quite interesting from a software architectural point of view and Siebren already discussed this back then in 2019 but the community was very happy with his first test and there were lots of very nice comments and they were very happy that he started testing USD and with that encouragement in 2020 in a version 282 Blender got its first USD exporter this exporter was somehow limited but it was working for example the hair was only exporting apparent strands and we had only perspective cameras and only alive particles but nevertheless it was the first time we could export stuff that we made in Blender as USD files and then I tested it here I have a black screen wow there's a video okay cool and this is a Amsterdam scene and this is the data from Google Maps you can nowadays import those data using the Blender OSM add-on and yeah this is the Felix Merites and I wanted to make some kind of nice smoke simulation and I decided to test USD for it because I knew from further experiences and tests that the Blender fluid simulation is a little bit slower than in Maya it's because for some reason we only use one CPU core for simulating the stuff and Maya uses all cores so it has some kind of advantage and so I just exported everything to Maya and it was working fluently it it was like a brace we had all the models I had all the camera animation I had the camera angle and everything and so I could let Maya make what it can better than Blender and then I composited it back in Blender so it was working very great okay let's go back to the timeline in the following years we have some improvements up on the exporter and in 2021 we then also got USD import before it was not possible to see USD files with Blender eyes but no it was and yeah there were some limitations of course but I was very happy that we had it here's another slide where I had another fun project I created 17 000 cubes with a note editor and what you should know about exporting a blender to blend files to USD is about the instancing USD is very much about efficiency and here please keep in mind if you want to have instancing already used in the USD files you need to instance collections and not objects now if you just duplicate link objects and you have 17 000 cubes and export it then you have a very big file because everything is written as a copy so after it made real but if you just instance collections then you will really have instances in USD so it's very nice okay let's go to the importer a remark on the importer I created a USD structure as shown here on the left and if I open it in Pixar's own tools it works like expected again we have the mesh data which is instanced in several instances with some small changes we call it overs in USD land and with the USD importer in Blender you must be aware that somehow it loses those reference I mean there's only one mesh data here but as you can see on the bottom right the blender outliner shows two different mesh data blocks so it just copies the data right now or this is the blender for importer and it also does not take the right names from the prims that I have given so my prims are called three instance one and two but for some reason the objects here in Blender they are called after the mesh data so this is something you have to keep in mind if you open very large scenes because then your memory will will be flooded very easily I think it's just a thing that they can change in the future okay what happened after 2021 we got more and more improvements in the material important export we no support uxp open vdb volumes we had we got the usd z exporter so we can export ascii data binary data as well as zipped data so our usd files become smaller we have improvements on hair and curves and we also no import primitive shapes so in usd there are some kind of classes schemes and you can call it data types and for example there is a data type sphere and you can have an instance of the data type sphere and this instance only needs to explain its name so it's identifier and for example the position and the size the diameter you do not have to make any comments on vertices edges faces normals uv layout because this is defined in the scheme file and Blender since the 3.5 is also supporting those primitive shapes so the usd files are very small and you can import also those and they are mainly used as collection volumes in for example interactive applications because they only need roughly approximations of your high level measures and then you often use very primitive shapes like a box or a sphere so next week when blender 4 is coming out then we have also skeleton and blend shape animation support and no exporters can hook in so those hooks are used if you export something to a usd file then blender just notifies your exporter hey I'm ready to write it down on disk and then your exporter can make some kind of changes for example as a reference implementation they showed how they can export material x so this is a format which also very common in our sphere and we have also the hydrostorm add-on coming to blender and hydra is a very nice thing it's an abstraction layer between the dcc game structure and the renderers so imagine if we have a lot of dcc's and a lot of renderers on the other side to make everybody of those dcc's play with each render very nicely you need a lot of software to write now if you have n dcc's and m renderers you need n times m software that does the interconnection and hydra is now put in the middle so all dcc's now talk to hydra and all renderers also talk to hydra so and instead of n times m we only have n plus m software to write and to uh yeah to use in order to make it happen and in blender 3.1 I also um tried the hydra add-on already and you can just switch to the hydra renderer and then you have a possibility to choose which render delegate you want to use so render delegate is the connector from the renderer to hydra and in 3.1 they had the pro render radion delegate shipped with the add-on and back then they also had some kind of node system for usd files directly in blender you could just import usd files and you could merge them and then you could just connect them with the hydra add-on and the hydra then tells the renderer how to render it and for example here I loaded the kitchen scene from pixar and yeah it it was working very well and it was very nice to see that if you uh switch on the statistics you see that only eight faces are in the scene yeah although I see a lot of a lot of more here because it's directly going to the renderer and this has some advantages with very large scenes because then blender doesn't need to reference them in its own memory space that's some kind faster and you have some improvements on performance okay this um usd editor is not part of blender 4.0 but the hydra software is and it's now comes with storm renderer the storm renderer is a reference renderer from pixar which they use to check for all usd stuff okay um delegates for hydra are popping up everywhere so we have delegates for arnold amry even cycles octane katana lux core moonray the omniverse ethics renderer pro render redshift render man storm and vray so it's very great and we can expect that all those renderers will play nicely in the future with blender because of hydra okay let's come to another piece of software it's the omniverse connector and the omni omniverse nucleus it's some kind of exotic software because it's not made inside blender it's made from nvidia but it deserves the right here to be named because it's great piece of software i um i have tested this and it's it's working great and if we are thinking back to the artist they have to export all their files to some storage directory right and there is where nucleus comes in so it's just a storage for usd data so in a big pipeline you can have a local server it runs the nucleus application and there you can export all your usd files and you can import from those nucleus back to blender or other dccs and what's very great about the software is that it has some kind of memory what has been exported before so two weeks ago one month ago it has some kind of registry and it knows ah okay this guy already exported this asset and it changed nothing so during export we just set a reference to a usd file that is storing the asset so it's very fast because not everything needs to be exported again it uses references all over the place and what they also did is to provide connectors for a lot of dccs um this is the omniverse launcher you can install it and then you can have connectors for your favorite dccs and so it's very easy to export to the nucleus and I just talked to Vincent they have a very nice pricing license agreement so if you are a small company very few people and only two have to work together at the same time then it's even free and for enterprises who have multiple artists working together then it costs a lot of money but for most teams it will be okay they can use it for free um for blender they are also about to provide that connector as an add-on but it's not yet completely supporting all usd features so it has some issues so if you want to export to the nucleus from blender it's currently the best way to use the blender for omniverse fork so they provide a fork of blender and there they have integrated that technology together with support for nvidia's material definition language yeah and um I was very curious how far it goes and in july machine gun studio released the persian bazaar on the unreal marketplace for free so they have some free assets every month with 250 unique assets and 40 prefabs up to 4k textures the meshes use heavily nanite and lumen for lighting and it's a very huge scene and there are some kind of statistics on the right and yet there you can see that you have 100 000 of prims which are drawn on and they also provided some cameras and the cameras has some kind of camera properties for example defocus that you can see here yeah so this is a huge thing to export and I just pressed export and was very happy what happened then that is cycles so 90 percent of the scene was brought to blender and here I could use cycles and I could render better images because of the global illumination stuff and past tracing stuff and cycles which is not provided in this fashion in unreal so I was very happy all the textures were there all the models the mesh data and even the lights the skybox was there so I could just start rendering out all the stuff in blender without having the hassle to export every tiny thing individually now I would like to come to some use the concepts which are not yet supported in blender and it's also very likely that they will never be supported in blender because they are so strange and different from how blender is organizing the scene you see here on the left side the blender outliner and you have some collections collections could link from library files into the short file and you can have collections in multiple blender files and then you can assemble all of those together in one short file and on the right side you see the layering system of gimp photoshop to the image processing applications and there we have in contrast to blender the idea of order so if you have a background layer at the bottom and the foreground layer on top in gimp or photoshop then you will see the foreground above the background in the flattened image right but if you interchange it if you have the foreground below the background then the foreground will not be visible so order suddenly matters and this is what this usd is in blender it's completely irrelevant if you have a collection on top or above in nether but in usd it is of very importance which order the layers the usd files have when you combine them together and there's something else in gimp and photoshop you have combination modes so you can combine several layers together for example you can take one layer only the colors another layer is is just multiplying their pixels to the current stack and this is also there in usd land and they call it composition arcs so the combination modes are called composition arcs and with that being said we can go to dive deeper into some concepts of usd we already know the term layer is just one usd file and it's similar to a blend file or the collection that is stored in a blend file then we have sub layers which is similar to all contributing library files that we have in a blender scene which is not very similar or there's no term in blender is a scope scope is more like a grouping of of assets and in my opinion it's it's the closest is if you have the asset manager and in the asset manager you can set up sources where you have the collections that are assets and those sources somehow group together the same kind of assets for the same topic so this is something which is induced the scope on the left we have been now and now we change to the right and talk about the composition arcs so the combination modes of different layers the usd over is something similar to the library overwrite we know in blender then we have inherits which is just using references and you can have one source and you can reference it multiple times in blender and if you change some properties via python for example of those instance then it changes in all other instances as well so this is in usd land and inherit but they have another concept it's called usd reference and here those instances doesn't know each other so you still use instancing and you have multiple instances of the same source but now you can set values for every single instance on their own and they do not share them and yeah this is a nice concept to to vary in a detailed fashion set up your scene your asset data then as there is a purpose in usd every asset can be assigned a purpose and they have three types of purpose guide proxy and render and those purposes determine what is loaded into memory so whenever you want to make animation with an asset you can switch to proxy then the high detailed measures are disappearing and they are already unloaded from the memory and if you just render you see and then you have to use the purpose render and you can choose this in edit time so during editing you can define okay from this asset I want the proxy look and from this asset I want the render look and from this I want the guide look or all together and this is what blender is not providing in this in this flexibility you have to decide during import time which purpose you want to import to blender you cannot unload them whenever you want like in usd but the importer allows it that you say hey I would like to have all assets in their rendered version then you have variant sets and this is a great great idea here I have also loaded the kitchen scene from pixel in the usd view it's an application that ships with the usd stuff from the open usd and here I zoomed into a pen and variant sets is one asset that comes in different flavors so the modeler and the shader artist they just set up one single asset in different flavors and the artist the animation artist for example can now choose which of them he wants to see in the file for example a one type or a new type of the asset or an asset in different colors and here I'm choosing just drop downs to switch the different variants of the assets and here I also do it for a can and so this is a very neat feature because then you can decide which type of look you want to have for your asset in your current stage of working with the assets okay then we have the payloads usd payloads payloads are just data which is lazy loaded so if you open the scene the usd scene then the payloads is not loaded with the scene data but you can then define hey for this asset I would like to have the whole payload all the stuff all the high quality stuff and then you can just press a button and to unload it again so it it's not only becoming invisible it's just also falling out of memory and this is important if you have very large scenes and that you have a limited amount of memory and then you need to unload stuff in order to make you a nice experience with working the assets and yeah we have also the usd stage which is somehow different to the blender scene and and stage implementation and I already mentioned that the order is no important in usd land which is not important or not considered in blender but there's something else the different compositing arcs they have different strengths so they can overwrite the values from other compositing arcs and this they call liver piece this is just an abbreviation for the order of composition arcs and L is for local stage so all values that you define in the top most shot a layer file it's called local and they overwrite all others then you have inherits then you have value sets references payloads and specializes okay let's come to chapter four we did some research how well is usd playing well with other dcc's from blender and here got read a colleague of mine did all the very difficult stuff and he loaded all those dcc's and and tried hey can they consume my blender exported usd file and yeah this is the result you can you can look it up if you use the link bit.ly slash a beacon 23 minus usd you can you can come to this presentation here yeah no i have the problem i am not able to come back to my presentation oh thanks for the help hopefully so let's continue some real closing remarks what's coming up in the future of course there is a lot of missing usd features and there's also a prioritization from the demands of the community and i'm sure they will have more and more features covered here in the important exporter in blender but of course there will be other stuff in usd that we will never see in blender because of the different types the scene is organized but it's okay i mean we can load all the usd stuff and we can write to usd and as part of a pipeline it it still works very well okay if you are interested in usd and you want to have some kind of introductory notes then you can click links on the left side it's very nice to read through it it's written in a in an easily understandable way and if you like to have the heavy technical stuff then you can switch to the right side we have remedy entertainments they wrote a book about usd because they built their own game engine completely around usd and that's it's very nice to read it's it's it has a nice flow and of course you have the terms and concepts are provided by open usd there you can read what they how they describe all the concepts that i that i have also mentioned today and if you want to look back where everything started then you can find here the link to the blog post from sybren back in 2019 i'd like to thank all the developers who are supporting usd and it was very nice i i just talked to them and they invited me to their developer meetings and they helped me out with all the stuff so they're very nice people and i learned a lot so um thank you very much and yeah if you want to hear more about usd then please join us this afternoon two o'clock in the mooting room above we will talk about the open usd alliance thank you for coming in case you have any questions thanks okay the question is what about shader conversion from blender to adini currently the best thing you can do is to export everything as baked flat maps so some shader nodes are already supported in the exporter but not all so the best thing is if you have a procedural shader tree make textures of it make only one principle psdf shader node connect the textures to the node and then you you can be certain that it's exported very well to other tccs in the coming future they will add more and more shader nodes so that will be not needed any longer but currently this is a kind of limitation yeah sorry the omniverse connectors also a lot of them have built-in distillers and converters so if you use the the houdini connector to omniverse it'll convert the materials and then use the our build of blender to import it'll also convert back so you can try the connectors if you're not getting a good good translation directly if i have a a scene or a mesh made by geometry node in blender is it keep aliving and importing into omniverse omniverse like create currently you have the limitation that if you use geometry nodes to create instances you need to make instances using collections yeah in the geometry node there's some instance point node and there you can say okay i would like to instance a collection and then you have you can use the the concept of inheritance in the use the export so it it brings the size of your files very small it makes them very small yeah and the omniverse connector as well as a blender built-in exporter is doing the same here so use collection instances and then it works thank you what about animation and deformers do do the usd exporter like supported all like lattice bonds and bend and simple deform or do we need to cache it in like like an alumbic way yeah for most tccs it it works by caching it as an as an alumbic mesh but in blender for they also support a skeleton export so you do not have to to render it out and make it flat so you can also support the skeleton so this is improving but not everything is just supported and not for any dcc yeah because i mean it's not that only blender is somehow feature incomplete also other dccs do not support all of those features yet so there is some kind of trial and error and you can check our matrix we have compiled to see which comparatively is there with with your favorite other dcc beyond blender usd editor and um usd exporter actually you said that it's not gonna be i mean blender is not going to be an editor but we're able to export usd files so what do we do in blender i mean as i said it's a simple question but yeah what's the difference it's a very good question um you have um if you have blender in the blender in the pipeline then it's very likely that blender is not for assembling all the other usd files together but it's just responsible for a single asset and then you have no problem you can just export a single asset this is how usd would do it anyway so every asset has its own file composing or respecting the structure of the department so for this application blender is working very fine but of course you will not have the support of all other usd concepts that you would have in other applications for example houdini is completely built around usd so this is a the most complex um yeah a coverage of of usd features maya is also very well doing it because when it was released by pixar they also um provided maya implementation so they had some kind of head start in comparison to other dcc's okay let me just come to you so yeah i was kind of just curious about um the possibility at the moment to introduce custom objects in usd like custom data objects or like in basically all the like the measures and cameras and stuff which they like have properties and need to be reinterpreted but like just to uh yeah just the feasibility and options around like if i just want to create my own little data structure and have that be passed around by usd and read by different dc's is that like something inbaked from the start or yeah yeah so this um usd has been invented to be extendable so you can define your own schemes and classes and then you can make instance of those classes and you have to provide of course to other dcc's also the specification so you can just make your own data types and use them which is also very nice and it's not it's not there yet in blender so you cannot have it in blender and maybe you will never have it in blender that they support custom um objects but maybe we will see just one quick thing about the question about editing and using blender um i too i'll show how we use um our drive sim team that does the autonomous uh vehicle training system uh drive sim is entirely built on omniverse the whole team has switched over to blender for all of their asset creation so we'll be showing how we use blender to create the assets then omniverse or drive sim in this case to assemble the environments and simulate the worlds uh so it's a great working pipeline between the two okay then let's rub it up and have a nice day bye bye