Unite Berlin 2018 - Optimizing Binary Deployment Size

so good morning everyone welcome to unite Berlin I'm very happy that we're finally doing this in my hometown so my name is Eunice HOF I'm a developer at unity one of the things I've been working on is our WebGL export and one question which I've always run into when helping people bring their content to WebGL it's the question of build size when you want to publish your content to the web it's very important that you your content starts up fast it loads very fast you want to want it to load as part of a web page to get there you have to make sure that your content is as small as possible also specific on WebGL everything has to fit into memory because you don't have file system access so we did a lot of work helping people bring the build size down so I decided to do a talk about that because it's also it's it's very relevant to to the web platform now there's just not working anymore but it's also an important question on other platforms like when you're when you're targeting mobile so let's look at why would you care about those size so when I say build sighs I mean the deployment size of of your build how much space it takes on the device how much how much space how much size people need to download before they can start playing your content the answer to that is pretty simple you care about build size because of user reach the bigger you builders the longer it takes for people to download it the longer its takes takes to get started playing your content so the higher that the bigger the build is the higher the chances that people might end up not downloading it or interrupting the download intentionally or unintentionally also the bigger you build this the more space it will take on the user's device which makes it more likely that people will delete it to make space for something else like I want to take a photo on my phone it says no more spice no more space left so I'm gonna look at what's the biggest apps and if you if yours is on top there chances are I'm gonna delete that if I think I don't need it very badly so to put this in numbers I read this article from from the UX team of the App Store the Google Play Store and there's an interesting quote here it says for every six megabyte increase to an apk size we see a decrease in the installer conversion rate of 1% so the instant version rate that's the amount of people who are looking at an app on the App Store who will end up having it installed on the device so a 1% drop an install conversion rate is 1% less users for your app so that directly reflects to your revenue so if you look at that everything you can do to reduce your build size every megabyte you can save directly translates into revenue another interesting takeaway from that article is that that these numbers are not a globally universal there's there's differences depending on your target markets so what the article also said is that the average app apk downloaded in emerging markets such as by people in the Middle East Africa and Southeast Asia 1/4 of the size of apps downloaded by people in developed market such as in the US and Western Europe reasons for that is that people tend to have less powerful devices with less storage space but more importantly less access to Wi-Fi in in emerging markets a lot of people are relying on cellular connections only which means that any download you do directly costs you on your data plan I actually watched a presentation about localization a while ago and one thing they mentioned there is they would they would have different qualities of their assets depending on the target market like when you're targeting a game for India you would use lower quality textures because the trade-off between fidelity and build size is a different one there because people are less likely to download your game if it's big if you are interested in more information on this I thought this article was very useful said it was called shrinking ap caid's growing installs there's a link here you can check out if you want to read this another reason to care about build size is the App Store size limits so if you want to publish your game to iOS the iOS App Store has a 150 megabytes over-the-air limit that means that any app larger than 150 megabytes cannot be downloaded on a cellular connection and can only be downloaded on Wi-Fi likewise the Google Play Store has a hundred megabyte app limit it's possible to have apps larger than that but the user experience for that is not good because I think there are some warning messages people have to deal with so when when I said that install conversion rates drop with build size these numbers are important to know because this is where there's some specific drops which are much higher so you probably don't want to publish an app which is just slightly over these limits then you should work very hard trying to get below those but there's cases where you want to be much smaller than this like when you look at the Google Play Store they recently introduced a new feature called Google Play instant where you can have a try Now button in the App Store interface and then you can click on that and the the Play Store will download a trial version of your app which will then instantly load without having the user to install it so this is a great way to get users interested in your app because you can just click on it and instantly play it but to use this feature your app can be no bigger or the instant version of your app can be no bigger than 10 megabytes till now 10 megabytes is pretty small it's possible to reach this in unity but then you'll see that the unity engine code itself takes up most of that so you have very little space left for your actual game and your assets so let's look more into how you can understand your build size the first question is how big is your built actually well typically that's pretty trivial to find out you make a built and you look in the finder or Windows Explorer how big it is on iOS it's a bit more complicated at least when you care about the build size as interpreted by the App Store for the 150 megabyte limit because Apple has its own metrics which involve compression and stripping of unused binary formats on your architectures so to understand the you build size relevant to the iOS app store the simplest way is to just upload it to iTunes Connect and check the size reported on the web interface now you can also on most platforms look into the build like here's the Mac app but that's really just a folder so you can look into it and look at the files you can see how much is executable code how much this data costs how much is levels you can do that on most platforms if you make an Android build you have an apk but that's really just a zip file so you can rename it to zip and decompress it and look inside but when we want to get more information of what's in those files the first thing you can look at is your edit or lock file the editor lock file is always written by unity when you run an editor session its location is platform specific on the Mac I think it's in your home directory slash library / lock / unity its you can check in the manual the location of that file so when you make a build in unity the editor log file contains the section called the built report and this contains some data on each individual asset and the size like each individual asset which was included in the build and the size it contributes and also a breakdown on how much of your build size is spent on different asset types typically the biggest being textures now this has been in unity I guess since pretty much forever but the data actually comes from an object called also called built report and we have started making some of that information available for better access through an API so in 18.1 we introduced the build report editor scripting API when you make a build using the the editor API using build pipelines or build player it will return an object of type built rapport which you can then get information on using the built rapport API it has properties like how long did the build take what were the individual steps during the build and how long did they take which files were written to disk and it also has information about native code stripping which I will get to later so this is all very useful but what I'd really like is some graphical representation of that information now we are working on at some point getting something like that built into unity we don't have that yet but now that we have the API we can build something inside unity and I spend some time doing that and I'm going to show that right now so let me switch to unity here's the unity editor and I have a script selected here called build report inspector as you can maybe see here it's just a custom editor on the built report class so I'm using the build report API to to get some information out of it not all the information in that object is already available through public API s so I used some tricks to use the serialization system using the serialized object class to get some more information out of it so now this editor script adds the menu item here open last built report we're gonna click that and now in the inspector I hope you can see that we see an inspector showing the last build report object here it has from some general information the name of the project I've been building we made an Android build and I have a few tabs here you can see that we first it build all the scenes then we compile the scripts we can also look into here there were some compiler warnings there's some more steps packaging all the acids in the end the last step was creating the apk package and then the build was done we can look at the source assets which contribute to the build so there's a list of all the assets by size we can also look at them by files written to disk or by asset types we can see the biggest by far here is textures audio is also big this project by the way is the 2d learn project included in unity which you can access from from the new project tab we can also see the output paths written to the disk since we made an Android build there's just one apk file and there's a tap on stripping information which will show you which unity modules which subsystems of the unity engine were included in the build code including information as to why they were included so like we have the physics module here which implements 3d physics and we can see that was included because there's a box Collider which is included because it's part of several scenes here I will get back to that later and I'm going to go back to my slides well now now this is the build report inspector I have submitted this to the asset store but I didn't get it approved yet so I just uploaded this to a URL here if you want to try it yourself I hope this will help people get some information on how to optimize their bolts I also hope that eventually we will have something like this built into unity but for now since we have the built report API we can you can get this information and I hope this helps getting getting drilling down into your build size so now that you get some information on which acids use how much size the question is what can you actually do about that what can you do to reduce your build size what can you do to reduces the size footprint of these assets so the first question you should look at is are you as is actually used so unity doesn't include assets in your build which are not referred by any of the scenes your building and you might think this question is trivial because you look at the assets end and you should know but if you if you have a big project it's very hard to actually keep track of why is this model used and why is this sector used you might have some prefab with a like a character which has a model and some textures which actually never instantiate in your game so it's it's interesting to find out what's actually referencing these assets unity doesn't have a built-in way to show you where references to assets come from but there's some asset store packages to help on that there's one called the asset user trainer which is a $20 package you can get on the asset store which allows you to pick any asset and then get a list of any references to it and there's also a free one called asset users detector so I recommend checking these out and just looking over your assets especially if you have any doubt if you actually need all of them the next thing I would look at is your texture sizes often when you work with artists they would give you very high resolution textures because as always makes sense to get high resolution data of burst and then you can use your meshes at any size and look at them really close but often for shipping your game you don't want all that high resolution now the question is how do you find out what's a good resolution for for your textures to use because in in the texture importer there's a drop-down for texture size so you can choose the lower size then the texture data actually is and then unity will just drop mid mid map levels higher than that and you you use much less size on textures in the scene view in the random mode pop-up there's a mode called mid map view when it chooses that you scene view will look like the screen shot and what unity will do is it will shade your textures in either red or blue depending on whether the texture information whether the pixel density is too high or too low for the current view and screen resolution so if you size your scene view to match your the resolution you want to target and match the camera to some views you care about you can get an idea if the texture sizes you use our sufficient and if you can get away reducing your texter sizes another thing I want to look at is the serialize scene data if you build a scene in unity that's basically a binary file containing like all your game objects in your scene and all your components with all their properties serialize to disk so sometimes you may have a lot of instance instances of the same objects in the scene like here's an example this is a component a mono behavior called a floor tile which you could imagine as a floor tile in a game where you can can run around and it contains some properties a floor tile might have like how the tile might interact with a player some objects like particles which might be instantiated when interacting with it there's some physical properties now if you look at this there's some boolean which are one byte each there's some floats which are four bytes and there's some reference types which are 12 bytes the total size of this is 112 pipes that's not much but you might have 10,000 of these in the scene which then adds up so typically if you have a lot of identical objects in the scene you have those because you you're using prefabs and and you have a lot of instances of the Prix preps so in the editor this will just be stored as a reference to the preview to the prefab file but when you make a build of a player like prefabs there an editor only feature so once you make a build all the prefabs are resolved and you know you have ended up having many copies of the same data on this so what you may be looking at doing instead if you have a lot of instant instances of the same or very similar objects it's to move that data into a scriptable object so here we have an object I call a floor tile data holder which is a scriptable object a spectable object is a is a serialized scripted scripting data which can be written to an asset file so now all this data is just in in one asset and then in your mana behavior you can just reference that data indirectly and then you just have one one reference type so especially if you have I mean this is a simple example but you might have more complex game objects of which you have a lot of instances where you also instead like have more components so you could have a simple data type holder which then on instantiation or on startup you would unpack to your whole acid this is an optimization you which may be useful if you have a lot of copies of the same data in a scene the next thing I want to talk about is compression so in unity there's there's two types of compression applied to assets one is like data file compression which is lossless compression and applied to all your assets there's a pop-up in the build player window for the compression method to use it has three options there's default compression which on most platforms is none some platforms a custom compression I Android for instance doesn't zip as part of the apk and then we offer l 0 and L 0 HC compression these formats are compression formats meant mostly for very fast decompression so they're not the smallest compression you can get typically which typically you you would use some more efficient compression in the container for distributing your games like the app stores would would apply some compression on your data anyways but this is relevant for the data size on disk because we when you use LZ for a zip or HC we will only decompress your data once it is loaded from disk and a z4 is generally so fast that decompressing it is faster than loading from disk so that means that by by using this you will not only save disk size but you will also speed up the startup times of your game because like yeah the decompression is faster than the loading um the other compression we have in unity is as its specific compression formats so for some asset formats you can get much higher compression ratios as then you can get by a general-purpose compressor if you have a compressor which is aware of the acid file format and can perform some lossy compression on that data so the first data type where we where we have that is meshes in the mesh importer inspector there's a mesh compression pop-up which allows by default is off and it allows three different levels of compression the mesh compression in unity is pretty simple it's just basic quantization of the mesh data meaning that we just store your vertices and normals and a lower resolution my general advice for any of these asset specific compressions is to try different compression ratios and see what you can get away with without visually losing quality poor meshes since we're storing the data at a lower resolution generally you can get away with pretty high compression on any mesh will which has vertices kind of evenly spread out and in space you have more problems if you have a mesh which is pretty big but has some very small details because then these tend to tend to lose their detail and might shift in position but yeah so just try different settings and see what looks well the next format where we has a specific compression is audio for audio generally with support arc Vorbis though on some platforms which have build and support for proprietary formats like AAC or mp3 we may use those likewise we have a slider which allows you to choose compression format and there's an input box below those settings which so show you the original and compressed size so once again choose play around with the setting and listen to the audio and see what still sounds well and the next one I'm going to talk about is textures and for textures we support we generally support on each platforms the native GPU formats supported by the platform so on desktops that is DXT or BC 5 PC 7 on mobiles there's different formats depending on which devices you're targeting that may be et CA STC or PV RT C what all these formats have in common is that they're designed to to reduce the memory footprint and video memory on the GPU so the the textures will stay compressed on on the GPU and there they are all block based formats meaning that a block typically by 4 by 4 pixels so some of other sizes but that you have a block of textures and that each block has the same size regardless of what's in it and this means that the GPU since each block has the same size can easily find the location of the block containing a specific pixel because it because it can just it knows the offset to it now this is very well-suited for getting the most out of the out of the GPU and the GPU memory but it is not the best way to store texture data on disk because if you look at general-purpose image compression formats like just like JPEG you can get much better compression ratios than this now the problem if we were using JPEG and unity is that with when you uncompressed JPEG you have uncompressed texture data which is not optimal for using on the GPU we could recompress it but then you'd have double compression artifacts and it would be very slow and this is a shame because texture size as we saw tends to be the largest percentage of Ezard data so what we added support for unity is a texture compression method called crunch now what crunch does crunch is a lossy texture compression method similar in characteristics and compression ratios to JPEG but it decompresses straight into a GPU format which can then be used directly by thereby the engine which will without sacrificing space on on video memory now we added crunch support in unity 5.3 but generally it wasn't used that much the reason for that is that we own that crunch only supports dxd textures so it can only be used on desktop and WebGL but not on mobiles where people care a lot about build size and the other complaint we got is that it takes much too long to run the compression so you have to basically run your project overnight to import all the assets so in 17.3 we added an update to crunch my colleague Alexander several Suvorov he has been working on this for a while and been digging into the crunch code to optimize it so in 17.3 we added mobile support to crunch by supporting a crunch based format which would decompress in T into e TC 1 or 2 we optimized the compression further so it's on average 10% smaller and we made it much faster so in in 1703 it's already faster in 18.1 we landed more optimization so on 18.1 on average it's 5 times faster to compress so if you have been evaluating crunch for your project before and decided it's it's not useful to you maybe this is a good time to take another look now the final thing I want to talk about for for the asset data size if you've done all these things and you find that you still can't get your build small enough you should consider putting your assets into acid bundles acid bundles and unity allow you to store assets in a file outside of your main build data I'm not going to get go into details about how to on how to do that because that's the subject by itself and there's a lot of tutorials and documentation about that but the dread the general idea is that you can move assets into files outside of your data and then load those dynamically download those and load those into the game dynamically at runtime and this allows you to defer the loading of your data into the later into into the play so people can get started playing your game very fast with a very small download and then you can offer them a slice of your game while downloading the next parts so you can you have you can get a budget better user conversion while still having more more data to load you can also cache asset bundles in unity so that you don't need to download them again every time you load now the next thing I want to talk about is executable size executable size is the size of all the code contained in your bill that's both the the native machine code for the unity engine it's itself and your managed code for for your game code and for all the dotnet system libraries which if you're using outer cpp also get converted into native machine code um now you might think why do I even care about executable size because executable size may only be a very small part of key distribution size that's generally true if you have a big project but as I mentioned there's a lot of use cases for targeting very small sizes like Google Instant apps is one example where you have a 10 megabyte limit so if your executable code is 8 megabytes you just have 2 megabytes left for assets so if you can save 2 megabytes of the executable size that doubles how much assets you can use it also matters like when you want to make a small starter seam for scene for instance for WebGL game where you want to have a very small initial download you can put all your assets and asset bundles but you cannot put code in asset bundles so your initial download always needs to contain all the executable code so if so it may indeed be very interesting to see how you can get that to be smaller so what unity does is it it supports code stripping now code stripping means that we analyze your your game and your executable code and we try to remove parts which unity considers not needed for the project and there's two levels of code stripping the first is managed code stripping on mono you can manually turn on managed code stripping for platforms which support it like Android in this pop-up in player settings an iota CPP managed code stripping is always enabled so managed code stripping basically looks at all your managed code and removes any types of functions which are not invoked and and generally this is meant to just work in some cases when you use reflection where you access a type or method by its name at runtime this may break so you may have to provide linker XML file where you whitelist certain types from being stripped now the other level of code stripping is native code stripping which is supported on il-2 CPP on WebGL Android and iOS currently so on these platforms you will see a checkbox strip engine code in the player settings if this is enabled unity will look at at your project and try to remove any modules of the unity engine like modules are components like the audio subsystem the animation system the physics system the 3d chosen for this system 2d physics system and it will look at all the API or the unity API calls you are using and it will you look at all the components in your scene to determine which of these should be used in in your build again generally this is meant to just work and in most cases it does in some cases when you use asset bundles you may have some components not in your main build and then you have to tell unity about that so that these are not being stripped but the problem has been that this is kind of just a black box you turn it on your build gets a little bit smaller or a lot smaller depending on on your project but we haven't really resupplied good ways to dig into what's going on and how you can optimize that and that's something we've been looking at changing so I'm going to go back into unity again here is the stripping view in the in the unity editor where we can see that the physics module is included because there's a box Collider in the scenes and also because it's used by by the scripting code so let's see where it says there's a box Collider in zone 1 dot unity which is seen I have open here so I'm going to search for a box Collider here and yep there it is so we could now go into the project and find all these components which are being used by physics and delete them and then go through our scripts and try to find all the cases where we use api's from physics and get rid of them as well but that's a tedious task and pretty hard to not miss something so we try to make this better so this as I said is the 2d platformer example included in the tutorial included in unity it's a 2-d game it uses 2d physics for its interactions it shouldn't actually need the 3d physics package to run so let's see if we can get rid of it so in 18.2 if you go to the package manager window we are exposing the built-in subsystems distributable modules through the package manager has built in packages so here you see a list of unity subsystems and here we have physics and I click on this button to disable it now we see the scripts of being recompiled and you will also see that the Box Collider we have here is grayed out and it has a warning message telling me that this component is excluded from the build and it will be stripped from any player you make and it will also be an inactive in in play mode also we got a compiler error here saying the type unity engine dot physics has been forwarded to an assembly which is not referenced enable the building package physics in the package manager window to fix this error yeah but I don't want to rename it solely I'm going to look at this code instead so here we have a lot lines that gravity equals physics or gravity so we're using the physics API to to get the gravity I guess that makes sense but then that doesn't justify adding a whole subsystem to the game so I'm just going to replace this with vectors read down times the constant gravity and I recompile this project and now everything compiles actually I've been taking a shortcut here because if you take the 2d demo project you see that there's more cases like this but I didn't want to spend half an hour of text in compiler errors on stage because I thought that might be boring so I did that before the presentation um so now if I make a build of this project you'll see that the build size was reduced by three megabytes of code per architecture so if you're targeting a small size this can actually be pretty significant so you can use this to to make unity builds which only use the sub subset of the unity and engine functionality and have a much smaller footprint for the engine size due to that so here I'm also pretty much at the end of things I have about optimizing your build size and unity but there's one more thing I want to mention that's unity for small things so as I as I mentioned there's cases where you need really small builds and where you where it becomes pretty challenging to to get to those sizes using unity in part due to the large size of the engine the Google Play Store the instant apps was one example other examples is WebGL especially if you want to target mobile games which is currently pretty hard with our WebGL export playable ads if you want to have an ad banner on a webpage build in unity you don't really want to download ten megabytes for that there's also games in messaging apps like iMessage has a built in has built in apps where you can play games with each other as has a facebook Messenger as has WeChat so at GDC this year we announced that we're working on a new runtime called unity for small things this is a separate runtime for unity this is not a part of the whole engine but instead it's a very small engine which compresses down to 72 kilobytes of JavaScript for the core runtime it runs on HTML canvas so it can run on pretty much any device which has a web browser and while it's not a full port of unity it uses the existing unity editor and asset pipeline so you can author content in tools which you are familiar with and you can also like if you have an existing project and you want to make a playable app or a playable ad or like an an instant game for it you can just you have all the assets readily available in in a format you can work with so you can use this very efficiently I don't have any news to share on this yet other than that we plan to release it by the end of the year but I hear you might be seeing a glimpse more of this at the keynote tonight we also have Latin the audience who's working on it so maybe if you're lucky you can catch him around the conference and that's everything from me for now but we have some time left so if there's any questions there's two microphones here so you can walk up to them and I can try to answer them [Applause] yes over there hello so when you step out for instance the physics module Anderson the build size is decreased but does also the memory footprint yes to the degree that all the the native code is also loaded into memory so depending on what you target that may not be a significant change but when specifically in WebGL actually the code size matters a lot for the memory footprint because typically the browser's tend to use a lot of memory for parsing all the code and converting JavaScript into native code so my answer would be yes it does affect the memory footprint but whether that significant depends on the platform maybe we take terms so then this one I have a question regarding asset bundles yes in our project we use a lot of asset bundles and some of them might local so they actually include it in the dog sorry I didn't get that some of them include it in the build some of them I don't load it from the internet yeah or in the runtime and some of them are right built right and it's really hard to work with assets that include it in the build because you don't really know what happened in wisdom it's not in edit or lock acid bundles is not in edit row' log and yeah and after that it gets difficult and tedious to so you mean like when you make an asset bundle you want to get information like a build report on that sure that's the first thing and if you have any asset bundles included in the build I won't at least have an information in general error for how much as a bundle these weights not with the contents of it but they're seeing itself so I think when you build an asset bundle the build pipeline API will also return built rapport object for that now so you could store the build reports for every asset bundle you build and and look into those for instance using the built rapport a tool I shared and then you can drill into each individual asset bundle and see how much the size footprint of all the assets in there is that said I don't think there's any built-in way to get an overview of all your assets in your asset bundles in one thing so I think you'd probably have to build that yourself yes that gets difficult and the second question is regarding texture compressions and what about you talked about crunch compression on Android with etc' support what about iOS iOS does support et Cie so you can use this on iOS as well does unity support et Cie for iOS it does I think we didn't expose it previously because it's not a format which would normally be recommended on iOS because there were no real advantages to using it over PV RT C or ASTC but now that we added crunch support for et Cie that by itself gives you a very big advantage for using et Cie so we added et Cie support in the pop-up menu for iOS I think if you target G alias - you only get a TC 1 so you don't get an alpha channel so you have to target that's GL to gles but if you target GL is 3 or metal you should be able to use HTC - yeah well devices it depends on device support so some devices doesn't support et Cie - but right yes that's really old well yeah it depends any device which supports GL es 3 or metal will support et Cie - so if you target only those devices you're good for using crunch on iOS otherwise you're limited to using crunch and iOS on textures which don't have alpha channels and since each which worsen of unity and et Cie is available on iOS it's it's in 17.3 where we added crunch support for HTC but maybe we can go back here because I see there's some I have a question also about textures I have I want to ask you if you unity plan to implement compression of uncompressed textures I mean lots less compression of textures this this is a subject we have been discussing and I think it's very worthwhile to do some research on that and see if we can build something similar to what we have was crunch but we don't have any specific plans for that so I would very much like to have something there at some point because it's you I and so I I agree and we are aware of the need yeah you talked about native code stripping without I'll to cpp where you would remove modules from the engine right yes does this affect custom plugins too so if I for example built my whole game only with plugins because I want to use my own compile process do I get the benefits of code stripping there - generally no code and your custom plugins will be used I guess if it is called somewhere I guess I guess we might depending on the platform on some platforms we link everything together and one binary so I'd assume that the linker would take care of any function which is never called on some platforms we would add custom plugins as several dll's or die ellipse and I think then we would not perform any processing on them okay but it's still well we we perform code stripping on the engine models depending on like some information we have saying this component is not used and so basically we tell the linker to only register engine models which we generate some code which only calls engine models which we are known to and then the link I can take care of stripping the other ones but I think that's very specific to our code so it should still work for the engine models like especially if you have all your all the code you use in custom plugins you would ideally hope that most of Unity engine code can actually be stripped out yeah hi I'm Dino I have a question if there is a plan to actually include scripts in acid bundles that sounds weird maybe at first it's not weird it's it's something people have been asking about before and it says there's no specific plans for that there's workarounds for loading code from acid bundles or from generic binary data if you are using mono on the platform which this getting because then there's dotnet API has something like assembly dot load from binary or I don't know what the API scope but it's possible to load dotnet assembly from binary data so you can load that into the game but on any platform which requires all the code to be a ot compiled we cannot do that and also the platform vendors don't want us to do that because like on iOS for instance all the code needs to be signed and goes through apple's review process so they don't actually want you to be able to bypass that and add any logic dynamically later on yeah I'm actually was going to continue that because the question maybe is weird like you just countered anyhow we are experimenting converting part of the code to Bassem and actually run it in the runtime just like a rag native app and actually doing a code push because it's way much more ler and that really helps us to decrease or abomino size because we are what much more flexible as soon we want to fix something not right earlier right so I have some thoughts on that but I think they they might be too long for this session but I am we haven't asked the experts area at the conference and I haven't figured out where that is actually but I am there today I think at 11 or 12 let me tell you yeah I'm going to be there today from 11:00 to 1:00 so if you meet me there we can have a longer conversation about that yeah thank you HIDA i'm speaking about the mesh compression have you considered using a library like Draco or corto to do this so we have been considering working on better mesh compression I don't know if Draco for instance would would suit our needs best I think we might end up building something custom and we have been doing some research because what we have has mesh compression right now there's something I built in a day ten years ago so it's not clearly not the best you can do but I think we have nothing other than ideas at this point so I guess yeah if there's no more questions then oh there's one more no okay then thank you for listening you

Channel: Unity

Views: 6,491

Rating: 4.9682541 out of 5

Keywords: Unity3d, Unity, Unity Technologies, Games, Game Development, Game Dev, Game Engine

Id: 4JLpJHIdx7E

Length: 52min 8sec (3128 seconds)

Published: Thu Jul 12 2018