Search the Community
Showing results for tags 'school project'.
-
Currently facing issues with file attachement //////////////////////////// OpenUSD Guide for (Student) Games //////////////////////////// Hello everyone! For the several weeks I have been looking into implementing OpenUSD into the pipeline of student games. The information that is currently available is more technical than practical or software-specific, instead of guiding you how to set up a pipeline. To fix this problem, I decided to write my own high-level guide for those who will follow in my footsteps, whether it be student like myself or individuals who have taken an interest in OpenUSD and its capabilities! I will leave out the in-depth research, as most of the information can be found on OpenUSD.org. Disclaimer: I will restrict this guide to Maya and Unreal. Houdini and Blender's approaches to the pipeline will be shortly discussed. This guide is also currently aimed at environment art, due to a lack of availability of other disciplines at the time of writing. //////////////////////////// Before we start, here is a quick introduction on the author of this post. My name is Sikandar Maksoedan, 20, I'm a 3rd year student at Breda University of Applied Sciences specializing in Tech art. I am currently looking for an internship starting September 2025. I am currently working on broadening my skillset in terms of Shaders, VFX and Pipeline optimization. I got interested in USD after my teacher Zoran Arizanovic mentioned the possibilities of the file format during a lecture some time ago, but only really picked it up after looking for a way to transfer a unreal scene to a different DCC while retaining all the data. //////////////////////////// Contents 1. What is OpenUSD (& Why should you care)? 2. How does USD function for Artists? 3. Introduction to Pipeline 4. Practical showcase of Pipeline 5. Closing statements //////////////////////////// 1. What is OpenUSD (& Why should you care)? USD, Universal Scene Description, is a file format that allows for the transfer of entire 3D scenes. This includes data from Geometry to Materials, from Lighting to Cameras, and more within this single file format. It shouldn't be grouped together with OBJ and FBX, it is closer to .MA and .Blend files. USD as a single file can be read in almost any major DCC with most of its features intact. USD allows the referencing of different USD files, allowing multiple people to collaborate on a single project at once. By layering USD files in sublayers, you are able to have your team work in tandem. Your level designer could be moving around props using a proxy mesh while your Prop artist is still modelling. The difference between using USD and a normal approach in team settings would be the latency. By updating a single USD file, all layers referencing this file will adjust their proxy on a quick refresh. Then, why should you as a (Tech) Artist care about USD? The advantages for both teamwork as personal work that USD provides are too big to be ignored. USD is like the PDF of games, a universal format that we won't be able to live without in due time. The scale of these advantages is big enough to have game studios such as Remedy Entertainment switching over already. Within the next few years, USD will be slowly adopted within the games industry. This means being able to work with it will be a skill required, especially for students. For all the advantages of USD, I will redirect you to the OpenUSD website: https://openusd.org/release/intro.html //////////////////////////// 2. How does USD function for Artists? USD for Artist should be kept as simple as possible. As stated before, this article isn't aimed at explaining all the technical details. USD can be used in 3 major ways for Artists 1. As a Container for single assets 2. As a Sublayer for a collection of Containers 3. As a Shot containing a collection of Sublayers Not all 3 have to be used to succesfully implement USD into your pipeline, but having all 3 gives you the most advantages. Lets go over usage 1, as a Container for assets. USD stores data in containers called 'Prims'. These Prims can have Parent-Child relationships with other Prims. Prims can contain Property, which can be divided into Attributes and Relationships Attributes consist of data such as the Vertex coordinates to form a mesh Relationships point to other data, such as which Material needs to be used In the proposed pipeline, you would create your Assets and store them in individual USD files. These USD files would be referenced in this Prim. Now onto usage 2, Sublayers Prims can be stored in Layers. Layers are akin to the scene hierarchy you would have in most DCC. Layers is where the Scene building happens. You can instance a Prim. This instancing references the USD file using it's local path, allowing us to change the Prim itself while keeping the reference. I have chosen to name the layers 'Sublayer', as you can have layers consisting of layers. This would allow you to have seperate layers for seperate parts of a level, each part consisting of more layers. That allows you to disable and enable parts of a level with ease, while also allowing you to for example work on the lighting or set-dressing of the entire level at once. You could also have Sublayers containing the Blockout of a level and work on a reference of that in your own DCC, lowering the latency between departments. Each Layer will be stored as a individual USD file containing reference paths to the lower levels. Usage 3 is last, The Final layer containing information of all the Sublayers is called a shot. Shots are the file you can use to preview all Sublayers and Prims at once and would contain the entire level. With this covered, we can go over to the actual pipeline setup that I propose //////////////////////////// 3. Introduction to Pipeline The USD pipeline that I have tested out for Games is fairly simple. But first, we need to discuss the role that USD plays in the pipeline. USD is practically an asset library in the way we will use it. We are creating assets that will be referenced by other people in their scene. The difference here is that we have automatic references to these assets, and once they are updated all scenes containing the file will also automatically update. Another advantage of the USD pipeline that we can open the files in any DCC to adjust it, whether it be a full scene or a single assets We have 3 hierarchies of files, the Shot, Sublayer and Container. Container will almost always be an Asset, so I will use these terms interchangeably. See Image 1 Containers will be the hierarchy where you will save your work to most of the time. These files are what in a normal pipeline your FBX files would be, as these files contain singular assets. Every asset gets an individual USD file so beware of naming schemes and folder hierarchies! If you want to work on a single USD file, you can. For texturing this can be nice. Most of the time however, you would want to work in a Sublayer. Sublayers will be the hierarchy which you will open most of the time. The layers are what in a normal pipeline a folder would be, whether in Maya or Unreal. Sublayers have the widest usecases. They can be used to store your own work like a .MA file, or as a part of a scene. Ideally you would have a Sublayer replace your .MA file, and use a separate sublayer to build part of your scene. Having multiple sublayers allows you to work on the same scene with other artists, since they are all individual parts of the same Shot Multiple Sublayers can reference the same Containers, and multiple Shots can reference the same Sublayers. Shots will be total sum of Sublayers and Containers. This is the file that will be loaded into your Game Engine. This file only needs to be accessed when adding or removing Sublayers. Proper naming schemes is key when using USD files, as there is little distinction to be made between the 3 types when they are on your disk. naming them with a prefix such as Co_, La_, Sh_ will already bring you a long way. I personally order the files like the following example: ------------------------------- -Level_01 --Shot_Level_01.USD ---Sublayer_Setdressing_01.USD ---Sublayer_Lighting_01.USD ---Sublayer_Buildings_01.USD ---Sublayer_BuildingBlockout_01.USD ---Sublayer_BuildingBlockout_02.USD -Assets --UserScenes ---Sublayer_UserScene_02.USD ---Sublayer_UserScene_02.USD --BuildingKit ---Asset_SM_ModularWall_01.USD ---Asset_SM_ModularWall_02.USD --Foliage ---Asset_SM_Tree_01.USD ---Asset_SM_Bush_01.USD ------------------------------- As you can see, We have seperate folders for our Assets and for the levels For a better overview different assets have been seperated based on types Users have their own scenes that reference specific assets So to quickly sum up what we have gone over up until now: You model assets and save them in Container-level USD files You assemble parts of the scene and save them in Sublayer-level USD files You combine all parts of the scene and save them in the Shot-level USD files Below you can see a more expansive overview of my USD pipeline. See Image 2 As you can see, we divide it up in Shots, Layers and Assets as mentioned above. We model and texture in the Asset stage, we can texture and assemble our scene in the Layers stage, and we can combine our Layers in the Shot stage. We Import the Shot stage into Unreal, but Unreal can both read and write to the USD files to edit the data. I have added OpenUSD viewer to the pipeline as I often use it to verify that my USD changes have actually saved. It also makes it easier to preview individual files and check if they are correct. With this info, we can go on to the practical pipeline example //////////////////////////// 4. Practical showcase of Pipeline The first step in the practical pipeline would be the setup of your Main USD file, the Shot, and its first few Sublayers. In Maya, enable the USD plugin to get started. By using the USD layer editor, we can create several layers and save these. They will each save as a separate USD file. See Step 1 You can easily add Geometry to a layer, but this causes it become a single mesh. See Step 2 A better approach that works for larger setups is using references to other USD files that contain the desired assets, whether it be boxes or horses. See Step 3 We are now saving the horses to a separate layer, allowing us to completely remove the boxes from our sight just like you would in the outliner. As you can see, the material setup and positions get correctly imported into Ue5 when using the Ue5 USD plugin. See Step 4 Changing the position of meshes in Unreal and saving will update the USD file, and refreshing in Maya showcases these changes. See Step 5 Changing your material setup in Maya changes the MaterialX parameters, thus changing it in Ue5 by extension. See Step 6 And that concludes the short practical demonstration. Once I get my hands on some more time and more assets to create a proper demonstration, I will update this guide. This concludes the basic pipeline, I will list some extra resources at the end of this topic. This is just a basic demonstration of the basic concepts, on how we can use different USD files as an assetkit to build larger scenes. Now some highlights as to why we are not using Blender. Blender lacks the simple UI that Maya has where you can easily create USD layers, Blender can still be used in the USD pipeline for individual asset creation, while the assembling currently has to be done in Maya, Houdini or Unreal I have left Houdini out of this pipeline on purpose as Maya is the most user-friendly, and thus easier to use in a student-game pipeline. Houdini also has plenty of documentation online on how their USD workflow and has plenty of support for the features in Solaris. You can check out Project Greylight for a practical example, which you can find on the SideFX website that will be listed below. I personally use Houdini as my main DCC, so I will update this guide later with a proper Houdini pipeline setup. //////////////////////////// 5. Closing statements Well, that marks the end of my short introduction to USD for student games. I have purposefulyl left out Variants and Classes, just to make the key pipeline of USD easier to understand. USD is slowly creeping into the head of students at my school, but sadly none seem too eager to try it out in actual production. With USD finally making it's way into the games industry, we students should be the first to jump on the OpenUSD train and learn how it works before entering the Games industry. I doubt this guide will get much attention on the forum itself, but for future students it would be nice to have some form of starting point. Currently I'm looking for industry people that have used USD daily and can help me improve the pipeline a bit more, and for Internships where I could possibly improve my understanding of Pipeline integrations. I am also looking into replacing GLTF in a custom engine pipeline with USD, giving not so tech savvy artists a chance to help out in these projects by using their preferred DCC. Thank you to anyone who read this through to the end, If you have any feedback to improve my pipeline or see any mistakes then please reach out!
- 1 reply
-
- student project
- school project
-
(and 5 more)
Tagged with: