 Hei, ydych chi'n syniad ychydig? Fynd am ychydig? Fynd am ychydig ymlaen i'ch hun i'r cyffreddau hynny'n cyffreddau hynny. Hei, mae'n cyffreddau cyffreddau hynny. Mae'r cyffreddau cyffreddau hynny yw'r cyffreddau sydd wedi'u gwahanol? Y dych chi'n mynd i'ch cyffreddau sydd angen. Mae'n ddaw'n ceisio'n mynd i'ch cyffreddau sydd angen, ac mae hyn yn gallu'r cyffreddau sydd angen. O가 a'r anodd y gallwn ni? I'm Brian Fuller. I use to work as an ATD at DNEG. I'm currently a Pipeline developer at Jellyfish Pictures. I'm a hobbyist animator, I'm a long-term led user. So long-term in fact I remember this. I also remember how I used to make projects. I would do a tutorial. I would save everything into one massive blender file. I would save those files wherever I liked, under whatever name I fancied at the time. I would duplicate whatever I needed, wherever I wanted. I would hide everything underground when I didn't need it. I would have very inconsistent asset quality. That's meant to be a clock and a typewriter. You could decide which one that's referring to. It would slow my machine down to a crawl. It would take extremely long times to render and be very noisy. This took way, way too long to make. A lot of talks have been going on the premise of building the tracks as you're going. This was like pushing a train across a road and saying, wow, it wouldn't be nice if we had tracks. You can see the sort of year and a half it took to finish this. This is the viewport from a real project that I did complete. This is everything all on show as it happens. I did this quite a while ago. Now this was in old blender. Everything like effects and empties were just left around. I just shot the rest of the shots tastefully to avoid actually showing that and fixing it. I call this the brute force approach, which is very fun and creative. It gets you in the zone. You don't really want to get rid of this aspect of it. It's good for very small projects. If you're doing a few seconds of animation or a logo, then most of these issues don't really matter. It does slow down production a lot if you're trying to scale it up, especially if you keep it being disorganised. It puts a lot of ownership on the individual. If you try and work with other people to help speed things up, it ends up being harder because you have everything in your head and you can't get it out as easily. No one can understand what Cube 23 is doing or what it's meant to do. It doesn't take a lot to make this way better. Let's have a go at this. Make your pipeline. A pipeline can be many different things in many different places. The definition I'm going to go with is just a system of rules and procedures that helps organise the flow of work. That just means deciding what work to do in what order. Let's try and do that. There are a bunch of really good solutions for pipelining that come with built-in bledder support, which are really great. This is not to replace those. These tools usually have a lot of pre-made assumptions that you know what pipelines are doing anyway. I think it's a good way to see if we can make a bare minimum, bare bones pipeline and see where that goes. It helps learn as well. We have our problems. Very long production times, inability to find files, messy scene habits making it difficult to work with, slow seed performance making it difficult to do things we're trying to do in that slow performance, inconsistent quality and being dependent on one person with everything just being in their head. Mainly my head. We can address these by planning what we want to make first and dedicating some time to experiment at the beginning. Figuring out a naming scheme for files and folders, so it's self-explanatory if people are coming into this, they can figure out where things are. Splitting up the files so that not everything is in one massive file. Keep only what's needed in a scene, making some basis to work off of. And making a list of things that we want to do as standards before diving in and staggering out the work into steps. Let's try and do this with the example project. A jam sandwich. This is a project, which is the step zero of any project, is inspiration. This is an example project of a guy getting hungry, going to make a sandwich, eating it. The sandwich has jam in it. This is going to help decide what pipeline we're going to make and how we make it. The very first thing, besides references, of course, is the storyboard. We want to plan what we want to make before we do it. A good way to do that would be a storyboard. This is not just a fancy maker, elaborate whole film before you make the whole film again. This is an extremely bare bones, get the idea out. It's a way of communicating your idea to yourself and others. That's a real storyboard for knives out, and that's someone who made Star Wars in ASCII art. A generic pipeline gives generic improvements. We don't know what we need unless we know what we're going to make first. With storyboards, you'll be able to work out stuff later on. This is me taking six minutes to try out a storyboard. I knew roughly what I was going to make beforehand, but this is just me solidifying it. It gives you a way of figuring out angles, composition, all that arty stuff, but more pipelining related in a second. Now, once you have the storyboard, you can make an animatic. Again, this could all just be done in blender. This is just those same storyboard images in time, so it gives you a way of figuring out the timing of things artistically as well, quite relevant, but pipeline-oriented. It gives us a few details, so we can figure out some details from the animatic. We know roughly how long it's going to be, and we can get an idea of how complex it is, so characters, assets, props, use of jam. We can also figure out if there's anything unusual to focus on. If we have a big crowd in the background at something that needs to all weave past a fluid sim, we know that's going to be tricky, so we can figure out and prepare for that. To actually make use of the animatic, we can start splitting it up. We know how to chunk out the work, but it could be that you want to just put it all into one file, but this will help move that around. If we take our animatic and export it as an MP4, render it, open it into another blender scene. This is just the editing tracks, and we can just start splitting it up. It might seem sensible to just evenly split it up into 10-second chunks, but we can also take advantage of some pre-established terminology. In standard VFX productions, they'll use some ways of defining what parts are on the show. In case no one here has heard of these before, I'll quickly go over them. In general, if you have a show, which could just refer to a movie, a TV show, a short film, all of them could just be called shows, they can be split up into episodes, so you could say an episode is a change in story, or if you're not doing episodes, you could just have a whole movie, and then that would just be the whole show. It's just like splitting up a street into different houses. Then within each episode or show, you could say every time the background or setting changes, that's a change in location, or a change in set. This could be an altercation in the story as well, it could be different arcs, it could be different acts, whatever you want to do. This could be like splitting a house into different floors. Then within each of those sequences, we could say that every time a change in the camera happens, it's a change in the cut, which could be considered a shot. This is just the smallest part you can break a film or show into, and that's a good measurement we could use. The goal of the storyboard is to get to the point where you can make a list of shots to disparate the work into. It would be easy to just go shot one, shot two, shot three, that's all the shots until you get to shot 3081, but we can also name these shots with some naming schemes. This is, well, if we're boiling down pipelines, pipelines are just naming schemes. If this is the one thing you take away from this talk that's brand new to you, then let it be this. Naming schemes, first thing to do, we're going to pick the name of our show and shorten it to be three or four characters long, because you're going to be writing it a lot, it'll take over your life, so having it short as possible helps enormously. Stuff like Macbeth will become MCB. In Summer's Night Stream you can just abbreviate it as well, just MND, and with Jam, easy, jam. Now we can look at the number of sequences. We have our animatic. We can roughly go along there and see how many sequences we have. Every change in set or story, and you couldn't count these up. For this animation I counted roughly three sequences. There's getting hungry, standing up to make the sandwich, and then eating it. This is one digit. We could express all of the different sequences in one digit. Let's add one more digit, because I'll bring up something later on that will help, but that gives us two digits total to contain all of the numbers of sequences. The number of shots. I've counted the maximum shots we have per sequence, so that's about six. That means still one digit, but with shots we might be editing stuff around as we go along. We might want to insert things. We might want to make more of them. We want to have extra digits for safety. We want to add the one from before, for a reason I'll explain in a second, just for safety. That gives us three digits to work with. Now we have three tokens, is what they would be called. We can now insert them into a naming scheme, and this is a way of saying, these values go wherever we want them to name. This can express the whole shot name. If we have those three tokens, we could say show name, sequence number, shot number, and this will define the smallest part of our show, which is the shot. You can also take away the last three digits, and I'll be a sequence name. That's it. To actually use this, we can make use of a coding convention, which is to always count in tens. If you're counting in tens, that means you have numbers in between that you can insert into. If we start counting in tens, that means that the first sequence is sequence 10, and the first shot is shot 10. That would be the whole first shot name, and the second would be sequence 10, shot 20, and then the new sequence would be sequence 20, shot 10. If you ever need to add a shot in between these two, you could just use a five, so count up in fives, and insert it yourself automatically. You can have that be on an edit, or if you're just making a new one, then everyone knows where it goes. Same thing with sequence names. If you have just the first two tokens, that's the sequence name, and you can make a new sequence, put in a five. That's the whole magic system. Everything else will just peg itself onto these names. If we name stuff like this, then we can say every single thing we have is responsible for that part of the show. This gives you a major benefit of stuff like just naming it shot one, shot two, the shot where the man gets shot. For instance, every operating system will sort name, if you sort it chronologically, or alphabetically, you'll get chronological order automatically. This will mean that anywhere you are, you can see what sequence you're in, and see it in order, or roughly where it is on the show. If you're working it at all, you can navigate them easily. We'll get to filenaming in a second, but the filename itself will be able to express everything it is, and when you're going through all of those files, they'll all be the same length, they'll all be the same level of detail, and you can tell roughly where they are in the project when you're going to them. The code of approach is just always a nice indicator. The downside of shots is that we have to be careful about continuity. If an object disappears and reappears between shots, then that's a bit of an issue, but we can figure a way out of that with something else later. Back to the animatic. We can now use the editor to cut up wherever there's a continuous camera angle change, and we can figure out where there's different sequences as well. If you use a marker, or you could use strip groups, grouping works in the graph editor as well, but it helps. We can now get our full list of shots. That's it. We have the full shot list, so now let's check out how many assets we're going to need. We're splitting it up into shots and assets. I just wrote down, based on what I saw in these shots, all of the different assets that I thought we'd need. I'm not going granular like the socks on the character, because we don't want to go that too deep too quickly. If we want to add things later, we can. Only get the things that Ibarra character interacts with. Is it vital for a composition or is it upset? You don't want to go too granular too quickly. Now we have our list of assets. I've saw grouped these roughly by what props or sets of characters they are, but these disc grouping will become handy later on as well. Right now it would be confusing if we had, say, jam referred to multiple different things. So be clear if you're going to name an asset, that it would say jam jar, a jam knife, or a jam character, because you have a character called knife, and you'd be confused when you import that into your scene. Now we have the shot names and the asset names. We don't actually have the asset names yet, because they are not formatted. They've got spaces, horrible spaces. We don't like spaces. We can per piece of information things. So we have the name here. That's not good. It has spaces. So let's try putting underscores in it. That's all right, but it's also meaning that the whole asset name is split across an underscore. Have we already established that an underscore splits one token and one token is one piece of information? So let's try camel case. That's getting there. But let's do full capital then camel case. Meaning that we now have a way of differentiating this from, say, a different word that's lower case. Oh, and if you... Fun fact is that Maya cannot have numbers at the beginning of our file names. Just in case that's relevant. And now we could look at the assets that we have, and we've got our list of them, and now we can categorise them. So if you have a different show with lots of effects, you might want to have effects as a category. You'd have an asset for all of those different things, but right now I'm just categorising it in the main ones for us. So sets, props and characters. Characters are just anything with a rig. Props are anything that is interacted with, or is it the background as dressing, and then a set is just a room. You could have vehicles, you could have set dressing as a different category. Yeah, that's a good way of keeping these organised as well. And then now we can get onto folder structure. So we'll get to Blender soon. Folder structure. We want places to store assets, shots and other files. So for now we'll have these three main root files. So we have the first folder which is the show name, and then we'll have assets, sequences and pre-production. And these are very broad root places to just keep those things stored. So the pre-production would be mostly for the edit, the storyboards, the animatic, those things you already have, but we haven't saved yet. So within this assets folder we've just made, we can now split this up by the asset type we've had earlier. And then now this means that you can navigate based on type. And then once you have those, we can now actually start putting the actual asset folders. And this is just setting us up for later. And making sure those are capitals and that those are not. That's another reason why they're not capitalised is because we want to make sure there's a difference between an asset name and something just for labelling. So back in sequences, we could do the same thing we did up for our shots. So we list out all the sequences we need. And then within those we list all the shots we need. And these are all self-explanatory as well. And you also get that handy timeline order as well. So to review, this is what it looks like in the OS. It's Windows, I know, sorry. And while we're at it, we can also make a file just at the root just to keep some settings in. So these are things that would apply to the whole show. Yeah, so like those sort of things. Which can contain stuff, for instance, locking your version. So if you don't currently lock your version, then there's a high chance you'll get a feature creep or you'll try and go, oh, there's something new in the new version. Let's try and use that. Try to avoid that if you're going into a project for a long time. In this case, I'm using 3.5.1, so I've not installed the newest one. It's taking all my willpower not to. Then we can have other things. Oh yeah, this also means that you can take advantage of the long-term a long-term support version. So this is what those are for. You get bug fixes, but you don't get new flashy changes. You could also set your scale. So if you want to have a character match the world size. So a blender, one unit is one meter. In other tools, one unit is one millimeter, one centimeter. So if you are importing other things outside of your project, make sure that the scale matches that just before you import it, because then you might in case have a system where you bring in, it's too big. Resolution FPS. This may seem silly, but there's a lot of companies that fail to do this that I've seen professionally. Then color space, blender's got a really good, decent one. You can pick one for yourself as well, but this is the kind of place it would go. Stuff that would apply to the whole show, not so anything specific, but because those all can change. So let's go back to the bit at the beginning where I said we want to keep the free form experimental part of blender usage. This is where it goes. We can now develop a look, which is what lookdev means. So we can finally open blender and start figuring out the main parts of the show, namely the jam. That's mostly the tricky part, is I wanted to make sure that the jam looked good, apply heavy use of references. This is why it's called look development. You decide stuff like the render engine, the render settings, the resolution, the general art style, and you could just have fun. You could do some tutorials. You can experiment, throw stuff away, keep it messy, no naming schemes, no nothing. This is the place to put it. Controlled chaos. So yeah, I wanted to make sure that I had the jam material right. I experimented, I found that just doing an ad shader, which always works. I knew I was going to use EV just so I could get quick render times. So I'm immediately benefitting from this step. So it means that now I've got that other way, I can put that into a lot of other places. So let's save it. So I've got the basic folder structure, so assets and shots. We know what those contain. They contain parts that are relevant to that asset or that shot. But within those folders, we want to put in more folders because we don't want to have a mix of many file types in one place. We want to have a single file relevant to a single folder. And there's many reasons for that, most of which comes down to if your naming scheme matches the same file then you get the same extension and some operating system and some software don't recognize the different extensions. But it also makes it easier to organize and see more clearly what it is. So for these right now, we've got scenes, renders, textures, caches. You could have effects. You might have sound. Sound I'll come on to later as well. But scenes is where you'd put the blender scenes, renders for any output renders. And so, for the name of the file itself, we know that the lookdev applies to a general whole show. It doesn't really apply to a specific shot because we're developing a look. So we can't go in a shot folder and it's not really something that responds to a sequence either because it's a whole show. But that means we can now just use that part of the name, which is the whole show. So then, so the first token will always apply to the part of the show it relates to, asset, shot, show. Oh, and another benefit of naming it like this is if you're working on multiple shows at once, you don't get confused about which show you're in. So the second part would be the kind of work we're doing, so lookdev, so like naming the stage of work. And then this thing on the right, which I will also come to in a second. And lowercase, just so it doesn't clash with any asset names that you might be calling lookdev for whatever reason. And bear my name. And that's now the name we can use to save a file. So within pre-production lookdev scenes. So now we can start saving the other files. So animatic, that's a scene, so we could call it animatic. The renders, that will go into the adjacent render folders. And yeah, the BL proxy will just be there. You can disable that or turn it off. Or just delete it afterwards. The edit, that was the bit where we cut up the animatic. That is just the same scenes folder. And same for the storyboard. So that little bit on the end where it says v001, that is a version token. And that is for if you have second thoughts. So the way most you can version anything is by two different methods. Source control and version control. Source control is like tracking all of the differences. Which this is an actual excerpt from the script for this talk. And this will track all of the changes from a starting point. Which is very good and convenient for code because you can see what's changed between versions. But it's very hard for larger complex files, especially files that reference other files. That's just a nightmare. So we don't want to do that. We want to do version control. Which is where you make an entire complete new version every single time and you give it a new version number. And you just make this number higher as you go along. And now the great thing with this is that it gives you the ability to make changes, save new things, but maintain the old one. And this was where you might use an external system like Excel or a spreadsheet to track which versions are good or which versions are bad or which versions contain what in them. But for this project we can generally just say latest is greatest. Never assume this for a big production. And the way you can use or the way we work on a file is to save it. Label it version 1 and then we can make any tiny adjustments we want while we're still saving. You don't have to make every different tiny thing a new version. But the next day you want to do a larger change, you want to do some slight modelling, you make a version 2. And then if you want to add materials or textures make a version 3. And then if you want to start something entirely new make a new version again. The more successful you are at maintaining a version history at a versioning system, the more successful you will be in working in parallel. Oh and yeah, since while we're at it turn off blend 1 files, this means you don't really need to worry about that. So, quick review. These are the things we've done. The time isn't proportional, the rest of the thing will be hopefully covered quite quickly. So let's dive into assets. So, now I want to make assets. We could just do it one by one, but that's quite repetitive. So we can plead up a little by making a base scene. So in a lot of places this will be called a shot build or a hot build or something like that. And this is where you would start making a file that has everything you need to start working. So we could do stuff like open a blender scene, give it some specific viewport lighting. So it means that all of your assets have the same lighting between them and you know what they're like in context. If they're all consistent with each other then they should all be consistent with any lighting you change in the scene itself. You can make premade collections to organise stuff. You can have all the rendering settings set up, all of the settings you found in the look dev and always enable all of these restriction toggles because I never, ever not open a file and not want to set these and yeah, save it and you call it, you will give it a new folder, we'll call it a base because that's sort of a new category of thing you want. And this can apply to all assets. It can apply to a type of asset. It can apply to wherever you want. We're based on the folder structure. So when you want to make a new asset you open this file, save as, start working. So when you want to start making assets I suggest starting with a character because this helps give a consistent scale, help gives a look for a feel and style. It's also the most complex thing so you want to get out of the way quickly. So don't be afraid if it takes a few tries. We also know that because it's got multiple rigs and multiple objects we could adopt a pseudo naming scheme for that so just try and be neat because Blender is quite good at this we don't have to worry too much about naming because most parts of Blender don't rely on a naming of a file or entity within the scene. But you can vary up a bit so making sure materials have MTL at the beginning, OBJs, collections, collections we do actually want to make sure that we have a standard naming scheme because we'll be linking those later. Oh yeah I also gave it a hair because I thought that's what all of the YouTubers do. So let's get in the groove of making assets. So you open the asset base save as immediately and don't forget this. I forgot it multiple times whilst making this so I had to make it again and change the name of the main collection to the asset name and then start making. So we've got some assets so now we're getting somewhere but with the other assets like the chair and the table they need to be interact with they need to be there for compositions so we can't really make them without looking we need to have a way of seeing what our assets look like laid out laid out laid out even if we have the best story board and concept art in the world some stuff will change in the translation so let's say lay out our assets in a scene before going full animation mode to see what they look like and this is where we open Bledder again we link in stuff that we've already made like the jam, gym and the plate and do this by linking not appending so you get the library overrides so you can actually interact with them because it saves on file size meaning we get to fill in one of those other quotas and it speeds up the interact with the scene a lot so if you start making a very rough model of the room, chairs and tables we get proxies that we can have for measuring the size measuring the scale, how it's going to work with composition and if you see that the scale is vastly off you can fix that in here as well so we make a new version of those assets relink them in scene hierarchy and reload and I'm avoiding trying to make this a linking tutorial but this is just saying that versioning can work hand in hand with linking so we've got this we don't need to worry about too much about cleanliness because this is more like the look dev step so we'll make sure the render settings are all the same but we don't need to be checking all the names we still want to check against the animatic and references so keep those handy here's where you'd also try out the camera angles of perspective even if you're not only making any specific shot yet you want to make sure that those look alright at this point but it also means that we can save this in the sequences folder as well if we are relevant to some shots so now we can finish all of our assets so we take those proxies we made import them into our assets base and then start making some of these assets and we can reference in the same way with the other ones did and now those assets are done we can finally make our set so now we have a new scene new model and it's just the basic room and we can link in our chair and table assets and then make sure that at this stage the key thing to check is the the scene name itself because we're actually going to be linking in the scene not the collection and that's important because it helps change what things are also with the world lighting if you're going to use set related world lighting so just like we did with the assets base file we can make a shot base file so now we're done with the assets we can start making some shots to make use of those assets so make a new blender scene minus the cube and we can add our render settings so resolution fps is good but we can also set a render output path in the rough area we want so right now I don't think blender could do string formatting inside the UI so you can't really have it done automatically without just scripting so that will be a manual step and but make sure you disable overwrite we don't want to have to overwrite a render we want to make sure that it's a separate thing and it also stops the image extension being on the end of the file extension we want it in the middle and there's an important part of this is an image sequence because image sequences are the ideal form of rendering because they let you pause pick up a render, download in batches upload in batches, minuscule file compression when you're actually doing video export and they let you re-render parts or maintaining the rest but the only big downside is no audio but that will come to audio again in a sec we also want to set our frame range to start at 1001 this is because we don't want to have some animation if we want to have to extend a shot to have animation beforehand we don't want to have to go into negative numbers because that makes it really hard to track what frame numbers are going on and if you have simulations then you want to have those starting before the actual start of the frame range so it doesn't just start playing and we want to enable those restriction toggles again we want to keep collections as well, neat and tidy so it can have like simple camera rig or we can put in stuff like cameras or lights and we can make a camera rig as well so if you want to have a very simple camera rig this is just a few empties parented to each other with a camera on top and this just helps make it easy to just get in and start animating once you actually open this file and lastly we link in our set so if this is a base shot file for a sequence we know that's going to be using the same set we can link in that scene file but we want to make sure that we put the scene file in this scenes box because that means that the scene is dropped in as a background it's not interactable it's not going to be clickable but it is going to be able to re-rendered and provide all of the standard scene stuff that was in your set which also saves on a lot of space and time it also makes it faster I think and then you could add in any assets on top of that as well and I know this feels like we've been preparing in like 10 different ways before we even start anything but this is where it gets really speedy so now we've got our full base scene just there and ready and save this start animating so all we have to do is now open that base scene save as, link all or any relevant assets still remaining and then just start working you can use the edit as a reference to roughly set the start and end frame you could do test viewport renders by just altering the output frame output path a little bit to make it so it has the like a token in it that says playlast or test render or something like that and you can take advantages of shots being separate files now so you can do stuff like parent a plate to a hand so that the hand's not sliding around or the plate always goes with it but you don't have to have that maintained between shots you can have like IK move between different places you can break the rig so that the camera looks nice in one particular angle and don't have to worry about cleaning up afterwards or you can add 10,000 metaballs for an effect you wanted to do and that doesn't make any other scenes slower so lighting that can also be done in the shot as well but you can also add lights to a set so it links in you can have most of the lighting and after animation or whilst you're doing animation this is also fairly free form and so we're doing a massive time skip now this is where you have done all your animation done all your lighting and you're about to get to rendering so now we can go through each shot and just hit render on them and that will automatically work fine except it never does so the beauty of versioning means that you can make every new version a new shot you can just have that be an entirely new brilliant brand new thing and if you wanted to try and do some automation or learn a little bit python then an automatic rendering script would be a very very good start so now that we've rendered everything we can import the new major sequence into a render scene and start arranging the shots and you can play with the timing, you can make new shots you can move around versioning up of course and now we get to audio so audio we use that many, I did lip sync for this animation but lip syncing is something that you'd absolutely need to handle with but that means that you can also treat audio as something that can be a shot specific file or an asset specific file so if you have footsteps or foley that can be an asset that you drag and drop later and use in multiple places or you can have a a very pivotal voice line that's specific to one shot be something within the shot and we also don't so if we don't care about doing the we don't want to have to worry about doing sound during animation so if someone hits over the sword we don't need to worry about sword swipe that is all handled in the editing and so an asset of music video you might want to think about having music split up or working that into the shots as well but that can also all be adjusted in the editing stage if you have a bit of play between start frame and end frame so once you've got all that timing down that leaves us with the final edit and this also means that we avoid having to have mob files that compress the audio once and then when we do an edit export we compress it again so this is what I ended up with this is the file animation play yep so this is a week or two of work whilst I was at work the just getting the pipeline ready to make this made it so much faster and I was just able to get things going it's not ground breaking incredible quality but it works there is audio but I can't play that and that's it and so I've skimmed over a lot I've completely bypassed steps as a folder I've completely ignored compositing I didn't even try to address plates or scans because I wanted to just give an overview a very short amount of time plus this brings up a point I wanted to make is that we need to keep it simple stupid which is a mnemonic used in programming a lot which is just to only do the things you need to do and not anything else it makes it harder and makes it slower so if you don't foresee yourself needing to work with vendors or make slap comps or do any other stuff like that then you don't need to but that being said if you are at a studio and they do ask you to do something that you think is unneeded or slows things down then please do it because likely the pipeline know that it's bad and it will look around an even bigger problem and so here's all the times I ignored my own advice I forgot that I needed to animate the desk so I had to make another set which had a desk missing so I could port the desk as an asset and link that separately I forgot that bread has slices so I needed to remake that asset and I had to import that back in I had to re-version it up because the parenting was gone and weird I forgot my own mnemonic a bunch I couldn't remember or seen and many more things I probably forgot but the improvement you get over just attempting to do this is far outweid by the little mistakes you make and the final message of this is that the only thing better than perfect is standard and that's it