Jump to content
  • Advertisement
Sign in to follow this  
TheTurkishMoose

Advice for LOD switching

This topic is 520 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm currently working on an open-world, dense urban project using the dev tools released by a design studio for a game they have released.

 

I can run the base game (which is also set in dense urban areas) at 1080p with ultra settings with a solid 60FPS but if I go to 4K then I get about 30FPS.

 

The minimum specs of the game:

CPU: 3.4GHZ

GPU: 1GB VRAM

 

The recommended specs of the game:

CPU: 4.0GHZ

GPU: 2GB VRAM

 

My question is about LOD switching. Using the dev tools, you can create your own unique buildings but I'm worried about how I should create the LODs. All the different buildings I create will use many similar objects such as windows and detailed objects like air conditioners, chimneys e.c.t. It seems more convenient to me to create many smaller LODs rather than creating a new singular LOD for every building that's made to save time and also, if I edit the values of a smaller decoration, it would take effect across all the other smaller LODs already created. I hope this has made sense to you.

 

If I create a LOD for multiple parts of a single building then I can keep creating new ones easily and all the LODs are already created. But of course, that could effect the performance. However, with minimum specs like 3.4GHZ, could I compromise with more LOD switches?

 

I'm new to generating and creating LODs and could use a bit of advice and guidance. Unfortunately, I cannot disclose too much about the project or show screenshots as it is currently under wraps. Any help would be appreciated - thanks!

 

Share this post


Link to post
Share on other sites
Advertisement
Does LOD stand for level of detail? You can't always assume every reader understands every
acronym. This is not a Game Design question. Moving to Visual Arts.

Share this post


Link to post
Share on other sites

Are you using a particular game engine? 

 

One thing that some engines support is the grouping of LoD hierarchies. This way a single building, made up of modular pieces - each with their own LoD, can be grouped together as a single LoD unit. That way, the LoD calculation is done on the group, but the LoD meshes are applied per mesh using the group's calculation. 

Share this post


Link to post
Share on other sites

Well, I have 3 things you could improve with your OP probably to get better responses:

 

1) I have a hard time understanding the problem and how the buildings are setup. Really, the explanation did not make a lot of sense, at least to me.

 

So, your buildings are not single meshes, but are compromised of submeshes. Right?

Your buildings share submeshes/parts between them. So the same chimney, as in, the exactly same mesh and texture, will be used as a submesh in multiple buildings. Right?

You are talking about a firstperson game, so you need MASSIVE LODing as stuff could be "in-your-face" close or quite far away (as opposed to pretty much always at the same distance to the camera in an isometric game)?

 

Going with my interpretation on your current situation:

 

2) You need to tell us more details about the dev tools, or engine used. Really, your question is quite technical, it is at the edge between visual arts and engine tech, thus to get the best potential answers, you need to talk to someone with intimate knowledge about the engine tech and configuration used. That would either be the dev of the original game if its proprietary tech being used, or someone with a lot of knowledge of the engine in question if an off-the-shelf engine is used (like Unity, Unreal or CryEngine).

 

Maybe find out first what technology or engine is being used before asking such deeply technical questions like how to setup your LODs best for max performance.

 

Also, at some point you will have to test yourself, for example if you cannot scrape together the information needed so anyone on this forum can really help you.

 

3) Max / Min specs are not really relevant here. Nor is the CPU Clock speed or RAM. GPU speed and VRAM maybe, but max and min specs here are mostly just guidelines, and very inaccurate at that.

 

More important would be the specs of your PC you tested the game on. At least then we know what FPS you get on what hardware. Make sure you switch off vsync first, because if you get EXACTLY 60 / 30 FPS, and your 4k numbers are HALF the Full HD numbers, your full HD FPS most probably are capped at 60 FPS (because the screen does not support more than 60 Hz), and your 4k FPS are probably capped at half the screens refresh rate, because the actual FPS are below 60, but above 30 FPS, so Vsync locks that at 30 to prevent screen tearing.

Expect 4k FPS to be about a quarter of the Full HD ones, maybe a third. Its exactly 4 times the amount of pixels to churn, and today the pixel stage is one of the biggest impacts on GPU performance in the GPU Pipeline. I would expect your full HD numbers to be about 120-150 FPS, and your 4k number to be about 40 FPS when you switch off vsync... or 200 vs 55 FPS, or 100 vs 31.... but certainly not 60 vs 30, unless the game is EXTREMLY light on the pixel stage (meaning no AA, no image effects, very low resolution textures and so on).

 

If you ACTUALLY have some test buildings, build a test scene with that, test the FPS you are getting and compare that to what the original game gets, you are giving the most important information on your Performance, the delta... do you already KNOW you have a performance problem, or that you will have in the future, or are you just EXPECTING that (given the scene you are building and the gameplay (being able to zoom out a lot for example), I would also expect it, but just wanted to know if you do so)?

 

 

Now, as to actual useful information.

 

The source of potential performance problems on the CPU AND GPU side is, pre DX12 / Vulkan, DRAWCALLS.

Basically for every new 3D object in your scene, a new drawcall is issued to the GPU, and the GPU has to be "Context Switched" or "reconfigured" for the new object. If you just start throwing 3D objects into your scene without any further optimisation, and these are all visible in the frustum of the screen, you can quickly run into thousands of drawcalls, which can quickly overwhelm your CPU (because the CPU has to prepare and issue these many drawcalls per frame, and depending on the game engine, needs to do that on a single core if the engine is not written to run the main thread on multiple cores).

And at some point the GPU would of course choke too, as it takes some time for this "reconfiguration" during which the GPU is not churning polygons.

 

Now, this has nothing to do yet with LODs. This is just one thing to keep in mind that NOT having LODs might not be your biggest Performance problems.

The Problem LODs are trying to solve are keeping the amount of visible polygons for the GPU to churn in a managable and stable region. Modern GPUs can churn WAY more polygons than most people imagine, problem today is more the pixel stage of the pipeline, which is more influenced by the textures, lighting and image effects.

But of course, again, if you just throw objects with countless polygons each in the scene without optimization, and then zoom out the view, the GPU will choke at some point.

 

I guess THIS is the problem you are talking about here, right? Which makes sense, given buildings are big 3D objects, and can be filled/decorated with MANY small 3D Objects, yet need to be visible from afar.

 

Now, I guess what you really are asking is how to organize your LODs so the full set (the building) can be properly optimized for minimizing drawcalls (so you want to batch objects as much as possible when sending the objects to the GPU), while still have a working LOD system to keep the amount of polygons visible to a managable minimum (which means the 3D objects cannot be statically combined, as then the combined object would need to be switched, not just the parts)?

 

This is now the point where the engine used becomes important. See, Unity for example gives you access to an optimization called "static batching". What this does is every object that does not move can be marked "static"... everything marked "static" will be batched into bigger objects, with the engine handling the batching so other engine optimizations like LOD switching still can do its things.

Its like the engine combines the objects for you before sending them off to the GPU as a single drawcalls.

 

On the flipside this means stuff that needs to move like doors cannot be statically batched. There are other optimization strategies for stuff like that (instancing for example), and under DX12/Vulkan you might just see if the batching of the API already takes care of your drawcall woes.

 

So this should be your first worry: how to make sure you are not choking your CPU with drawcalls when setting up your buildings compromised of many small 3D submeshes.

LODing the many subparts of the building is then as simple as using a separate LOD for each subpart if these subparts are just added as their own 3D object (because they are batched by an automatic optimization like the "static batching" in Unity, or because they are just instanced objects).

Just keep in mind that not all optimization strategies are automatically compatible in all engines, and some of them have their own limitations to keep in mind. Read up on the engine you are using, and how LODs work there.

Maybe using LODs breaks other optimizations like batching or instancing, IDK.

 

 

Of course, given we are talking about a simpler usecase (buildings for an isometric game without moving parts), you could just build your 3D object from the submeshes in a 3D app (like Blender), bake all the textures into a single Atlas (basically creating a single texture that combines ALL textures for the submeshes), and this would give you the optimal performance for a single building. A single mesh built from all the submeshes, completly static so the most basic optimization for multiple buildings would work, and a single texture so you can keep the drawcalls to a minimum.

Creating the lower LODs then just means assembling the same building from lower poly submeshes, and baking their textures (which most probably are lower in resolution) into an atlas again, using the result as the lower LOD level in your engine editor.

If you need to have moving parts, you could still go with this and use a simple rig with bones to make parts like doors and such animatable. This would result in a slightly more expensive mesh though, that might be incompatible with some game engine optimizations (like static batching, or instancing in Unity for example).

 

But again, without more information about your usecase this is a game of guessing what you need exactly.

Edited by Gian-Reto

Share this post


Link to post
Share on other sites

Really, your question is quite technical, it is at the edge between visual arts and engine tech


Then maybe this should be moved to Graphics Programming?

Share this post


Link to post
Share on other sites

 

 

Does LOD stand for level of detail?

 

Yes it does and sorry if I put this thread in the wrong section.

 

 

 

One thing that some engines support is the grouping of LoD hierarchies. This way a single building, made up of modular pieces - each with their own LoD, can be grouped together as a single LoD unit. That way, the LoD calculation is done on the group, but the LoD meshes are applied per mesh using the group's calculation.

 

Yes the LODs work with a hierarchy system. I was curious about how many of the small details should disappear or change to a lower LOD before the entire building does. Should I put more stress on the CPU or GPU as I am not sure how many LOD switches a CPU can usually handle.

 

 

 

Also, at some point you will have to test it yourself

 

I have been and so far it doesn't seem to make a difference however I set up the LODs but that's only because there isn't enough buildings populating the area yet!

 

 

 

More important would be the specs of your PC you tested the game on. At least then we know what FPS you get on what hardware. Make sure you switch off vsync first, because if you get EXACTLY 60 / 30 FPS, and your 4k numbers are HALF the Full HD numbers, your full HD FPS most probably are capped at 60 FPS (because the screen does not support more than 60 Hz), and your 4k FPS are probably capped at half the screens refresh rate, because the actual FPS are below 60, but above 30 FPS, so Vsync locks that at 30 to prevent screen tearing.

 

My spec:

i7-7600K 4.2GHZ

GTX1080

32GB Vengeance RAM 3200MHZ

 

I'll try playing without Vsync to see if I get more frames.

 

 

 

If you ACTUALLY have some test buildings, build a test scene with that, test the FPS you are getting and compare that to what the original game gets, you are giving the most important information on your Performance, the delta... do you already KNOW you have a performance problem, or that you will have in the future, or are you just EXPECTING that (given the scene you are building and the gameplay (being able to zoom out a lot for example), I would also expect it, but just wanted to know if you do so)?

 

Yeh I'm expecting. The actual game designers made their buildings much more different from me. They created entire blocks of buildings that all looked the same and made one LOD to that entire building which is why I'm worried with the way I'm doing it. The two reasons I can't and choose not to do it this way is:

 

- I want to make a  more varied amount of building styles

- The tools the devs had to make the LODs are not completely given to us which is really annoying. The devs barely give any support and it's down to the community to figure out the best way to work around the issue.

 

 

This is now the point where the engine used becomes important. See, Unity for example gives you access to an optimization called "static batching". What this does is every object that does not move can be marked "static"... everything marked "static" will be batched into bigger objects, with the engine handling the batching so other engine optimizations like LOD switching still can do its things.

Its like the engine combines the objects for you before sending them off to the GPU as a single drawcalls.

 

That sounds like an awesome feature! Unfortunately absent with what I'm working with HOWEVER! I could create this myself using the hierarchy system in the engine.

 

 

Just keep in mind that not all optimization strategies are automatically compatible in all engines, and some of them have their own limitations to keep in mind. Read up on the engine you are using, and how LODs work there.

Maybe using LODs breaks other optimizations like batching or instancing, IDK.

 

I'll be making it a priority to get the info I need!

 

Thanks GIan! You've given me plenty to think about

Share this post


Link to post
Share on other sites

I'm worried about how I should create the LODs

 

see how the game does it with the assets that come with the vanilla version.  if it does LOD per building vs per building component,you probably should too, but test both to be sure.

 

also, if I edit the values of a smaller decoration, it would take effect across all the other smaller LODs already created

 

that would be an engine specific feature.  try it and find out.

 

A Gian says, vsync is the probable cause of your 60 vs 30 fps.

Share this post


Link to post
Share on other sites

Okay, one thing to keep in mind is that the machine you got there is pretty epic. Its basically at the bleeding edge of gaming machine just below enthusiast intel CPUs / multi GPU setups... great to get the best possible gaming expierience out of modern games yourself. Not so great to test your scene for the rig most other people will have (not many have a GTX 1080... actually, not that many have upgraded to a GTX 1070 yet I guess, the GTX 970 was a big hit and I don't expect many of those guys having upgraded to Pascal when their GPU is still plenty powerful for Full HD and some 2k gaming).

 

Soooo... whatever you build, make sure you can test the scene on a lower specced PC too before releasing it to the general public. If you are getting a stable 60Hz on your rig, most people might struggle to get 30Hz because they have way less "ooomph!" at their disposal.

 

 

Then. Keep in mind just because the original devs built their buildings as one big fat mesh, and you want to build it from many submeshes does not mean you cannot combine things before you import it to your dev tools (engine editor, whatever it is called in your case).

IF you don't need movable parts (do you?), and if you don't need procedural buildings (didn't mention it, gotta ask still), I would build the building from the part submeshes in an application like blender, combine them to a single 3D object, and bake a Texture atlas. You do that the same way for every LOD you need, just with the lower poly submeshes (or at some LOD Stage, you might omit some 3D submesh that get too small, either because they are now baked into the texture of a bigger submesh, or simply because they become so small you can just omit them).

 

What you get now is just as "monolithic" as what the original devs built. It doesn't matter for the game engine if your 3D Object is a single or multiple submeshes as long as everything is combined and the textures are baked into an atlas. It gets sent to the GPU in a single drawcall (or as few as possible given the shader needs multiple draw calls), and you can swap LODs just the same way as every LOD is now one monolithic object.

 

 

Again, it depends on what you are trying to achieve here. My solution works brilliant for an isometric game where everything in and on the building will have about the same distance to the camera, thus everything needs to switch LODs at the same time. That is pretty different from a Firstperson game where the camera can be "inside" the building, thus a table might be 2 meters away from the camera, the next wall 30 meters. The table needs the highest LOD, the wall might have switched to a lower LOD already because of the distance to the camera. In this case monolithic objects might not work as well.

 

Given the original dev worked with monolithic objects though I guess it is not a firstperson game?

Share this post


Link to post
Share on other sites

see how the game does it with the assets that come with the vanilla version.  if it does LOD per building vs per building component,you probably should too, but test both to be sure.

 

They did create a LOD per building but did not distribute all of the LOD meshes such as low detailed windows, walls, roof and doors

Edited by TheTurkishMoose

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!