[Music] hello my name is Alena ham this talk is called make your game run on the quest and look pretty too we'll be talking about art optimization on the oculus quest VR headset now how to make art assets which will look good and perform well we'll cover the basic do's and don'ts for asset creation and setup and how visual choices can impact performance so a bit about me and why I'm giving this talk I'm a 3d artist and art manager at the indie studio phenomena here in San Francisco I spend most of my time creating art assets breaking down our assets and setting up assets in game I worked on the title Luna as shown here which was my first VR title since then I've worked on a few more a our VR projects including two VR projects developed exclusively for the quest our first quest project was in development before the device was released and the
latest project is releasing in about a month or two unfortunately I can't show stills from either of these projects today so I have to bear with some of my art tests so why am I giving this talk well even though I had already shipped a VR game when we first got our quest devices I was honestly pretty mystified and not a performance engineer so there's a lot I don't know about how rendering works but I still needed to make a lot of decisions about how to make art assets for this device it was hard for me to know what art assets were going to be a problem and what was not should I treat it like a mobile phone or like of the art game or a VR game running on mints pack and how it all dis affect the overall look at the game I wasn't sure there were some guides and documentation that got me started and there are fortunately more now but the guides in the documentation were pretty technical what I needed was more practical less
here's how the hardware works guidelines geared towards art production and direction that covered a wide range of our asset types tools techniques and their limitations so that's what I'm trying to put together here a practical guide for those of you who are new to the quest but we really want to make your game look beautiful in this cool new device its meaning of the quest let's start there how cool is it that we have a mobile VR headset now honestly I had a lot of fun after the quest launch sharing games with people in unexpected places did you know it still works on a train but what I love about this device is that it really changes who can access VR most people don't get sick from it since the sixth off is pretty good but also you don't need a gaming PC to run a VR app those two things alone just blow open the doors on who can access VR in a lot of the talks I've seen this is normally where the speaker would explain the quests cool new tile renderer and how it's able to do what it does because
it changes the buffer fragment meet more or whatever but I make art so if that interests you please learn about it from an engineer what you need to know or what I needed to know is what arts restrictions as a mobile device when it comes to rendering what are its VR restrictions and what are the special quest only restrictions because restrictions aren't bad they just change the artistic decisions we make and so we need to know what they are so we can learn how to work with them I'll go over a variety of these restrictions or performance guidelines whatever you want to call them the first one I want to discuss is the one I had the least familiarity with when I started my first quest project let's talk about draw calls I sometimes go to schools and tell classrooms full of kids what my job is and how cool and creative it is they always seem to ask it's art but you use computers so do you do a lot of math I usually lie and say no because while I
do some math every day it's usually pretty simple and anyone who can learn to use a 3d modeling program and probably learn to type 360 you / whatever into a calculator so now we have to do some math but again it's simple draw calls or how many times in every frame the computer needs to draw an object these drawings stack up into layers and create the final frame a PC can have several hundred draw calls per frame and not slowed down but the question really needs you to keep that number under about 120 an artist actually have the base impact on this number so we need to make sure we don't add unnecessary draw cause while we make art for the game because 120 is a very easy number to hit okay time for the math first each separate object is a draw call so if you have for example a character on a plane with a skybox then
you have three draw calls one for each character plane skybox okay that doesn't seem too bad maybe make sure you merge environment pieces as much as possible right well second each separate material on an object is a draw call okay that character actually has four different materials applied well that's a draw call per material so we're at six four on the character plus one skybox plus one a ground plane okay the math is easy but as a 3d artist I need to use different materials and objects a lot counting drawer calls isn't something we're used to needing to take into consideration so just by keeping this math in mind when setting up models and textures you can keep this number down try to keep each separate object whether static or skin to a single material if possible atlas textures and merge meshes in environments where you can cool so we can make better choices when setting up
materials and models but we can't keep track of the whole game in her head so we need to be able to look at what the actual number of draw calls is during runtime to make sure we're on target so let's talk tools there are a couple tools I use a lot to keep an eye on performance or try to figure out what's affecting performance the first of these is render doc render doc connects with requests and allows you to capture single frames from the game and break them down into calls and other information you can use it to find out if something is taking more drop calls than you anticipated or something is rendering on the wrong layer or one time I was able to find there was a non optimized light that was casting shadows everywhere and I had overlooked it it's just a really great insight into the nuts and bolts of the images being drawn especially because draw calls can be a big performance hit on this device it's very useful to be able to look over that information even as an artist so here's a screenshot from render doc I've
highlighted here where the draw calls are listed and you can actually tab through each draw call and see what's rendering you can look at the textures being used and the basic mesh that's being drawn as well there's a ton more information you can get from render doc but just being able to inspect the draw calls and see what's being drawn has been a lifesaver for me second of all frame rate this top could also be called how to make your game run at frame rate on the quest because frame rate or frames per second there's probably the most important performance indicator we care about in VR you need at least sixty preferably 72 frames per second a little frame lag on your phone or console game and it's annoying but frame lag in VR can make it player feel sick or even fall over if you make the most beautiful VR game but it runs at 30 frames per second no one will play it and everyone who tries will get sick so
you can use any FPS counter that you want but oculus puts out a tool called of your metrics which basically outputs performance information on the screen most of these numbers don't mean much to me but if that frames per second counter is at 72 I know I'm good if it's below say 65 I should probably fix something and sure it might be something non aren't related which is taking your frame rate but let's be honest it's probably the art in this image every option is this blade which looks insane I usually just leave on the frame for second graph and counter maybe a few other things I couldn't get screenshot of how I set up mine though because it doesn't seem to show up in regularly captured photos or a render doc additionally if you're a total nerd you can just leave OVR metrics on under quest and see what the frame rate of your favorite games is managing to achieve sorry developers okay really quickly
let's go over some basics for setting up mobile VR rendering I don't want to dedicate a lot of time to these but I think it's worth mentioning to get started their forward rendering depth fast rendering single-pass stereo anti-aliasing and fix motivated rendering forward rendering you'll need to use forward rendering the crest is a mobile device and that's the rule for mobile devices right now make sure you find out what poured rendering entails and means as far as art assets the biggest bummer here is that decals don't work in Flour rendering mode so you'll actually have to hide your texture scenes properly in unity you can use the lightweight render pipeline which is part of their new scriptable render pipeline it's set up for forward rendering and a few other things which are really helpful in VR I found this to be really cool and useful without even using the full power of the new script will render pipeline and in real if you're not doing some magic like pulling
a different branch of the engine their settings for VAR gun during are here in the project settings depths rendering there's no depth rendering the hardware just doesn't do this I think so no fun shaders that use depth info this includes soft particles but don't worry this doesn't mean you can't have some kind of fog it's just not as fancy we'll revisit fog though later a single pass stereo is a technique which saves you performance by basically drawing both eyes as one image rather than drawing one eye and then drawing the other eye this is on by default and unities lightweight render pipeline and an unreal it's here in these settings you need it you want it its anti-aliasing without anti-aliasing things look ugly really fast in forward rendering mode you have multisample anti-aliasing and four times as good if your performance can handle it eight times is a bit of overkill depending on your game style I think but
use what you can get away with it's in the project settings and unreal and in your lightweight render pipeline asset and unity alright one last thing for general rendering settings is fixed fogey ated rendering this can come in handy especially when you're stretching your rendering budget as much as possible what this does is it lowers the pixel resolution on the edges of the screen so they don't take as much time to render that part of the image this works because the output image and in VR is a little warped or fish-eyed to accommodate the distortion of the lens so there's a little resolution wiggle room in those areas that are being squished at the edges and this isn't necessarily a trade-off we perceive less detailed information in our periphery so the player may not even notice it too much and you could potentially save quite a bit of performance although if done somewhat aggressively fixed fovea tag rendering can creep further into the
middle of the render to the point where you can start to see the drop-off in resolution pretty obviously these images show what part of the screen is affected and how much there's a left and right I love fixed bow via dredging only affects a little part of the screen and doesn't drop the resolution that much but turned up high more of those communitive and the drop-off in resolution is a lot stronger you can see this a little bit more obviously in this render of the Occulus home here i've turned it on low and high for comparison you can also turn it off altogether of course particularly on the couch and on the dome cross beams you can see the pixelation that occurs in the higher contrast areas as the resolution drops so I've played some games where it was obviously set up pretty high and I really only noticed it when standing still anytime I actively played and was looking around it became less noticeable but another as I found it could be
really distracting even if it was on a more moderate setting if there was a really high contrast values in that part of the screen things such as stars become really noisy when the resolution drops that said if you use fixed ova turd rendering the start subtle so there's not a hard line of resolution drop in the players view and be aware of the noise it might make in high contrast areas now that we've covered the basics of performance that's really jump into the artistic side of all this first lights and shadows lights are already a known source of performance issues so there's no surprise there there's a reason we have things like light matte baking and light and shadow distance calling etc lights are expensive but how to light your game is also when your biggest artistic choices so how do you
balance what you want to do with what you have time for because with enough time and effort you can have a pretty nicely lit game in in the traditional PBR sense not a next-gen console or anything but pretty darn good someday the games have set up really great lighting but the catch is it's probably all baked down if you can bake it you can probably have it which sounds like an easy answer and there's absolutely nothing wrong with doing that it's a very old and well use process and it can yield really great results but it takes extra time and effort to make baked like it didn't look good and it's important to think about whether your projects timeline can afford the amount of time it takes to do light mapping if you only have once you've seen the light probably not a big deal of light method but if you have 12 well you'd better have a pretty big team then so can you have non baked lights yes you can have one
dynamic or stationary light they're much more expensive at runtime because they need to update every frame in order to change how the effect moving objects such as the player's hands most mobile devices can't handle too many dynamic lights but one is enough for your needs if you're careful especially if you're baking down more complex lighting also why waste computation even if you can get away with one directional light and the whole scene and still have it look okay still thinking about baking out the static area so you've wiggle room for other things what about dynamic shadows yes but dynamic shadows are probably have the worst performance impact out of anything light and shadow related so really think about how much you want them and where you can only have one shadow casting light at a time so if it would look odd or you'd have to spend time you don't have orchestrating which light is casting shadows when then think about whether they're worth having at all I personally recommend just leaving them
out unless everything else is running really light then you can get away with some object casting hard shadows no soft shadows for example here bonfire and half-and-half both use them but both these games are only rendering a few characters at a time and have a pretty limited environment if your game looks like one of these then sure the half-and-half example is the closest with the players shadow and they look fine as hard shadows and they're actually a lot of fun to play with if you're going for something more realistic or have a lot more things to render then save yourself the headache and just try and do without them the quest is probably not the best platform for your shadow puppet puzzler what about unlit looks or looks with the simplified lighting if these kinds of styles could work for your games aesthetic then I'd recommend using them for example virtual virtual reality it looks great on the quest it's a go-to example for me because I've played it on both the rift and the quest and I really
don't notice the drop in the art quality on the quest it seems there aren't any dynamic shadows in the game the characters and the player moved objects don't cache shadows but static meshes have shadows so I've assumed they've been baked in it almost fools you into thinking that more things have shadows than they do especially since the objects then themselves are cel-shaded so the illusion is pretty complete another example is nog which technically isn't a game that's out on the quest but it is out on the go and I've always thought it was a great use of the unlit style it's bright and interesting on its own and since this game wasn't developed for VR initially I assume it's just the style choice so if a bold graphic style works and then use it also styles that use faked lighting or light and shadows that are painted in can look really good and save a lot on performance totally
unlit is going to be the easiest to make performance and PBR is going to be the most difficult and time-consuming bear in mind your projects timeline and resources and try to find a balance of what you can do but is what you really need for the aesthetic goal of your game next up is shaders materials and textures so here you must need to remember that mobile devices need things to run a little lighter I mentioned the lightweight render pipeline earlier and things like that will get you far but you also have to keep a count of what's going into your materials textures don't go crazy on texture resolutions this isn't one of those next gen consoles running a 4k textures per character is a mobile device and crunching all those pixels has a cost in addition to texture size be conservative with the number of textures needed for each material use
what you really need and what can really contribute to the look because they'll add up over time what this means artistically is that some cool PVR looks that require a ton of textures at high resolutions aren't going to perform well maybe if your game is limited in the number of environments and props needing textures you can push for that look but generally you want a look that requires less Maps overall you can still texture everything in your game while keeping things performant but be mindful of what you're doing use some tiling textures try to use reuse textures as much as possible also don't forget to pay attention to your mid levels and filtering or your beautiful textures will look like Pixley garbage shaders obviously shaders can have some impact shader complexity is measured in the number of instructions and you can preview shader complexity in some engines to kind of keep an eye on how complex things are getting overall on the quest it's good to ask if you can
get away with a lighter shader and test complex ones that you make it's also important to keep an eye on the number of textures needed in the shader and how much of the screen space the texture will fill on my first quest project I spent a couple of days trying to figure out what was impacting performance on one scene before we discovered it was the water shader the shader didn't seem that complex but since I acupiont an extended way into the distance it ended up being really expensive to draw all the textures over and over a quick redesign of its looked really increased performance and that seen a lot that said don't be afraid of shaders at all some instructions are really lightweight and shooters are kind of beautiful math magic that you can use to make really interesting effects and styles in your game on my most recent quest project I opted to use a style of texturing which uses gradient swatches instead of unique
textures in the style you add a light and shadow gradient to the color swatch and then adjust the models you v's placement so that it sort of looks lit initially I was going to do the gradients in texture and bake them down in Photoshop but I experimented with setting that up in the shader so that I could just the gradients and what their color was room to room and create a slightly different lighting look so while the shader is more complex than an unlit shader it still has less performance impact than a lidar and it gives me a lot more control over the look I'm aiming for materials one thing which is quest specific there's a slight performance hit every time you draw call switches materials or switches shaders so if it's drawing an object using one material and then goes to the next object it's using a different material or different shader there's performance a so there's a big
incentive to atlas as much as you can and try to reduce the number of unique materials needed so maybe you have for animating props in a scene for example which are similar looking but all different rigs and therefore different draw calls you still get better performance if those four skinned meshes are all using the same material even though there's still separate draw calls it might also be advantageous to limit the number of shaders being used in a scene for that same reason splitting out functionality that you don't always need in one shader tutu sounds smart but if you're using both quite often maybe just see how it performs if you just use the more complex one for everything again it really depends on how many objects and how complex of a shader as a 3d artist my first question when starting to develop for the quest was of course what's my poly count the initial numbers I heard from oculus were pretty understandable given that it's a mobile device and I had made mobile games before but 3d artists we always want
more Poly's so I couldn't just accept the number I had to be sure so the poly limit given by oculus is 50 to 100k Verde's which is okay I've made do with less but I did some tests ok so just because some static mesh tests with no physics or lights or gameplay can handle half-a-million Poly's doesn't mean that's true of the final game scenario but I have consistently overshot oculus is recommended poly count in almost every scene I've made and so long as the other systems are kept light I can almost double the recommended numbers in fact on my most recent project I opted for style which demands more mid poly models but has a really lightweight shaders and textures and uses no lights at all so I can get away with needing extra Polly's in that style it did some tests and found out that most of my scenes in that project averaged about 150 K I did start
hitting some ceilings but only when I was being really lazy with my poly count and again everything adds up so if you really want a PBR look with lights and some dynamic shadows maybe you don't have the wiggle room in your poly count and you should aim for the target that oculus gives I was I think that I was only able to really push this number due to the lack of lighting and textures in my project style so what about the classic methods of loader lowering poly count they're still there and they still work so that's good but they have a couple caveats as well instancing yeah it can really help with poly count but remember our draw calls only certain kinds of instances actually draw on one call and some types still render each instance on a different call so you you might save Poly's but add draw calls and since draw calls are more of an impact hit be cautious with instancing and make
sure that it's also batching the draw calls together well let's guys batching more in a moment LEDs are also a great way to keep your poly count in check I would particularly recommend that you use LEDs for foliage and other things which repeat a lot depending on which engineer using certain instances will also work with LEDs so you can kind of get away with two-for-one combining them to one draw call and still using LEDs okay so what can you do artistically when working with lower poly count first of all remember that all games involves some amount of poly monitoring even next-gen games don't just throw ZBrush sculpts into the engine so even if you don't want a low poly aesthetic you're already working with a normal pipeline you just need to be a little more cautious than on a traditional platformer and keep an eye on how your attempts to reduce poly count may affect draw calls second think about in racing a low poly look I actually really love
low poly styles and generally model low poly stuff it's not everyone's cup of tea and it certainly doesn't work for every game but it can work for every type of game and even if a low poly style is not what you want for your game looking at how visual problems are solved with less Polly's can help you overcome poly count problems that you're dealing with this is a difficult thing to show examples of because it's one of the places where artistic creativity and technical implementation really intersect without many rules but as an example foliage can be difficult to make performant especially if you're trying to use a lot of cards so looking at foliage in low poly games might help you find a way to create foliage which still suits your game style but doesn't rely on all those cards you can still hit the visual target you want by learning to construct an asset in a different way just look at these games regardless of the final poly count which I don't know
because I didn't make these these games lean into a certain low poly aesthetic such as faceting on the enemies and super hot or the chunky shapes and job simulator or the simplified graphics graphic shapes in virtual virtual reality they all look great and distinct from one another so even if you're a little cautious poly count is probably not going to be where you hit performance walls I really only see this being an issue for pretty large scale games with lots of large environments and lots of foliage but that said looking to low poly styles to solve various visual problems may help your game look more polished than simply trying to traditional high-to-low pipeline and just forcing it even lower all right back to batching speaking abilities and instances and poly counts I'm gonna draw jump back into our draw call math and discuss matching I found matching to be really useful and I feel it's important to cover the matching options so
batching is when the engine takes in normally separate objects and draws them all the same call as a quick example this is what happens to all the quads that are generated in a dust mote particle system so that each particle is in a draw call so that's batching but you can also batch with regular static meshes in the game which sounds great but batching isn't going to magically solve all your draw call needs they come with some strict rules too but knowing what's going on with batching can help you set things up a little better I don't want to get too into the weeds because there are different methods and rules depending on which engine you use but what's important is figuring out whether the batching is costing more performance to compute than just adding some draw calls and merging meshes it's something that which may be on a case-by-case basis depending on what kind of lighting are using or other things which may affect performance but at least it's good to know what tools
you have there are two types of batching and unity dynamic batching and static batching unity will dynamically batch objects under 300 verts which is the same mesh and material there are a few more rules to this but the point is that it largely happens without you having to set much up the drawback to dynamic batching is that it comes with some computation per object batched so if a ton of objects are being matched together it might actually not save you much performance but for a smaller number of objects it's actually pretty great and then there's static batching marking an object as static and unity tells unity that the object doesn't move and therefore can be batched this static batching works with higher poly objects than the dynamic badging basically what it does is it merges meshes together into one object and then draws that using separate calls for different materials this means it comes to the higher memory overhead since it's saving
out that merged mesh so again you don't get it for free but it is a great way to consolidate your scenes after set dressing there are a couple methods of batching and unreal as well the main one is instant static meshes unreal already deals with instancing meshes pretty well but converting some static meshes into a proper incident static mesh will combine them into one call however you can end up with this kind of situation where I have really combined all my draw calls but I've also far exceeded my poly count and nothing is getting called and the LOD is aren't working so my advice is to go straight to a different type of instance when working on the quest from in realm and that is the hierarchical instance static mesh these are my favorite you kind of get everything here LOD x' batching meshes into one call instance calling they're kind of amazing the only drawback to hierarchical and
some static meshes is just working with them since you can't comfortably move the instances around however it is pretty easy to create a tool which runs it through all the instances in the scene and converts them to an AI hierarchical instance static mesh if you really need a lot of instancing instances of something hierarchical instance static meshes are really the way to go in unreal I've used these a lot especially with natural elements like rocks which can ticket duplicate it out quite a bit and of course not all Polly's are the same skin meshes are more expensive because they're being deformed and I don't think there's really any benchmark for how many skin meshes you can have per scene or how many Polly's can be skinned versus static it's going to depend on your games overall performance as well as the rig itself higher poly meshes or skin meshes with a higher of influences per-vertex are going to be heavier the number of vertex influences
can really hit performance this isn't true for just the quest is true for most platforms particularly mobile platforms so when painting weights on skin meshes I try to stick to two to three joints influencing each bird as much as possible I will do three for things that need to be really smooth but I would recommend not going above four and balance the number of joint influences you have in your rigs against how many animating meshes you need at any given point this is why the quality levels can adjust how many bones influence of vertex it's just a big impact on performance if you're still unsure about how many animating meshes you can use in a scene run some tests use a scene with static poly count that's a good average for your game and throw some rough rigs in I just added multiples of five to ten until I start to see performance drops too many animating characters can be a quick way to tank a framerate but at the same time you want to use as much as you can because the animation really brings
games to life bear in mind though that animation controllers with a lot of layers can also impact performance so if you're planning some really intense animation controllers and be sure to test those as well issues around transparency is one of the aspects of the quest that's not obvious transparency isn't a big issue on most platforms probably because of the differences in the hardware but transparency objects need to be handled with a lot of care when developing for the quest the problem seems to stem from overdraw which is when multiple objects or multiple Poly's are being drawn on top of one another this already affects performance because you're taking time to draw things which maybe aren't even seen but overdraw is basically unavoidable to some extent in all games it becomes a problem on the quest is when one object is transparent and so both objects will affect the final pixel in the image in this example here I've
put the wall in front of several other objects and you can see that those objects are still being drawn but you can't actually see them that's an example of overdraw and transparency you're drawing all those objects but multiple of those objects are affecting the final outcome small objects like dust motes or text don't have a big impact because they don't overlap each other a lot and don't occupy a lot of screen space but larger transparent objects like large cloud or fog cards effect sprites or even head bubble transition fades can be a real performance issue especially if you're struggling to keep your frame rate up my best advice to you is to avoid using transparency techniques that can occupy a large part of the screen especially if they're going to layer a lot you can use transparency here and there but you need to make make sure to keep it as small and infrequent as possible and test it
on the quest whenever you're going to add something like this so because transparency is not normally a big issue for game art it gets a little tricky to work around not using it so here are a few quick tips don't use big soft cloud or fog cards for soft particles you need depth Pass rendering and you which we don't have on mobile so they'll just clip through hard meshes and they won't look great anyway I find sometimes that really soft alpha cards don't also look as good in build as they do an engine so be sure to text test your effects on the headset the old style of fog linear fog or vertex fog the form is really well on the quest I've really pushed this and made it do some really interesting things so as long as you have enough vertices to support it it can work really well try to avoid using plant cards or foliage cards there are other ways to make plants than just cards explore some styles that don't use
as many cards and maybe rely on Polly's for the plant shapes for sprites use meshes fitted to the image to reduce as much overdraw as possible engines and sprite support software already makes this really easy to do so there's no reason to render everything on big quads especially since you're not as confined on the Polly's also you can pick a more graphic look for effects and use meshes instead of transparent cards here on the right I've made some soap bubbles and rather than using an alpha for transparency I've kept the style really graphic these are mesh renderers they still read clearly but I don't have to worry about performance as much for these also there's a setting in particle systems called max particle size which is really helpful it'll prevent particles from taking up too much screen space so that way your frame rate won't drop just because some dust mote got really close to the camera and using the full screen mesh fade for transitions is easy but
can also affect the framerate and if you're already pushing performance maybe try some different transition styles or build it into the shader and if you do use a mesh for transitions make sure to disable the object when it's fully transparent it should only be visible during the transition so if you develop for VR at all do you know that post-processing is already somewhat problematic and not just for performance reasons some post effects just don't translate well into VR largely due to the differences between the images shown to each eye however there are plenty of things like blue color correction or color grading which are really helpful on the quest however the tile renderer makes any traditional post-processing really slow like really slow because that post means after all the draw calls are done and sending the back image back through to get processed again is really a bad idea on this hardware so while it's one of
the biggest performance disappointments for art on this platform it largely just means that the traditional or built-in post-processing tools are not going to cut it you have to implement what you need in other ways color correction for example can be done before the image is complete you can add color correction into the shader and adjust it from there even seen the scene using global parameters cards can be used in places where you really really want some bloom since you can't get a whole image style bloom pass but the thing to keep in mind with post-processing is that it's just a tool to achieve a visual goal if you can't use the tool you know it doesn't mean that you give up on the work that you needed it to do assess the effect you wanted and figure out other ways to get those results visually so I've talked a lot about testing things to figure out what could be affecting your frame rate or before I'm committing yourself to a
new technique or asset style all over your game but what makes a good test to find out what's affecting performance in a scene I start by eliminating or changing the big offenders and making a build with those changes for example I might disable or change the lighting scenario or try removing a complex shader sometimes I'll replace high poly meshes with lower poly ones just to see if reducing the poly count helps I ran this test one time on a very frustrating scene where I replaced every mesh with a cube just to make sure that the poly count wasn't the problem version control is very important here because you can revert all this this is the same garden scene that I've been using through the whole talk but I've just selected every mesh filter and replaced it with a cube obviously the poly count is going to be a lot lower so if I still had problems at this point I can eliminate a couple things the best thing you can do to keep
performance and check on the quest is the test often during development that way if the framerate does drop suddenly you'll kind of know what's new and seen and therefore most likely the cause there are things to be cautious about while testing though or you'll end up with misleading information so now I'm doing this example here I've put some fog cards into a really lightweight scene mainly to show how bad the clipping looks but there's no lights and hardly any textures hardly any geo or other effects in the scene so of course it's still running at 72 frames for a second nothing else is going on the scene isn't representative of a finished scene in the game unless it is well then the act is this the important thing is that you try to make your test scenes have the same complexity so that you're using a reasonably similar number of draw calls or using the same lighting complexity if your test scene is really lightweight to render then anything you test in there may behave differently
when added into a more completed scene in your game so how do you translate all this information into decisions about how your game looks from the beginning well most importantly know your budget how big is your game how many people are making this game what is their expertise what does your timeline look like if the answer to these questions is you have a lot of people and plenty of time then try to make your game look like whatever you want you can afford to spend time to explore and finesse the performance if the answer sounds like most games you have a few people in a less than ideal amount of time then aim for a style or make choices within your desired style which eliminate problems and overhead on my most recent quest project we had a pretty short production timeline I had done this piece which you've seen throughout the talk as a test of using the gradient swatches instead of traditional texture maps before I even had the project get started look I didn't even use the whole texture map but for this really short project I
opted to use this method along with an unlit shader and they saved a lot of time not having to worry about creating textures managing Texel Dex density and adjusting lights and I used that time in other places like effects and animation and shaders so don't feel like this form an art style around your time and resources and then you can focus your time on making your art look good instead of focusing on making it perform and while the two are never inseparable spending time making your game look polished is always better than trying to squeeze in new techniques that you don't have time to optimize so in summary tests often and keep an eye on your draw calls the cautious with lighting and shadows and try to set those up smart in the beginning so that you can save yourself trouble down the line you'll need to get creative with some things like post-processing and transparency since a lot of the traditional methods can affect performance if you're not
careful but generally try to have fun and make what you want because you can achieve some really great art on the quest by just applying a little knowledge of how it works thank you for listening to this talk if you would like to contact me or check out more of my art you can see my website or catch me on Twitter I'm Lina's teapot or Alena Hale on most platforms so I'm pretty easy to find thank you again for listening I hope this was really helpful and I hope this helps you make some more great VR games
Auto-generated captions from YouTube — names and numbers may be misheard.
Distilling the key insights…
Game Developers Conference · 2026
PocketGamer.biz · 2024
Comments