You're blocking ads, which pay for BlenderNation. Read about other ways to support us.

Easy Level of Detail Using Drivers


Jonathan Lapel demonstrates how to use drivers to dynamically change the subdivision level (or any other modifier parameter). It's a nice 'hack' to simulate level of detail.

Game engines have long used level of detail (LOD) meshes to save memory. The idea is to dynamically change the resolution of an object depending on its distance from the camera.

While it’s not a true level of detail mesh-swapping system, we can easily change the values of our modifiers based on how far away the camera or character is. This especially comes in handy when you have a large number of detailed objects in an animated scene.


  1. If you really want to SLOW your viewport down - this is the way. Every modifier update takes time, the higher the subdiv the more it takes. Decimate modifier is even slower, it can take seconds to update!

    The proper way of doing LoD is to have multiple instances of mesh and switch their visibility, not through modifiers.

  2. @Jaroslav that's not accurate, you have to point the driver to the render and not the display modifier, hence, the viewport wont suffer the updates which will only be calculated at render time, if it's an animation, loading times will be penalized, but if the choice is between this or vram overload..... I'll take this trick anyday. Nice tip Jonathan btw.

    • So about rendering:

      Polygons are not that much of a problem to store on GPU. 500M of polys take up just 68MB in VRAM. The render-time difference is negligible - between no subdivision and 10x subdivision on object covering the whole render the increase is only 30%! Now consider on objects at distance that take up just small amount of pixels on screen this has very little effect. And of course the modifiers still need to update between frames which can take seconds.

      What actually takes up render time are light bounces, compared to them, polygons are nothing. Where polygons still matter is viewport (and game-engines).

      Also varying the subdivision based on distance will mess-up subsurface creases - they are dependent on the subdivision amount - the more subdivision the more creasing.

      Having the ability to do something doesn't mean you should. This is an example of a over-complication to not to do.

      • I don't think anyone has said that this would help render times, it can have an effect (negative) on loading times, but that's about it.
        This is just a neat trick to try to push more polygons on relevant information to the scene, the (unique) objects in front, and reduce them on the (unique) objects far away.

        I'm not sure were you got those numbers for memory usage. I've done a simple test, first I've rendered a simple cube on a plane, thats 7 faces, GPU-Z indicated 939Mb vram usage, then I've subdivided 8 levels the cube, getting up to almost 400.000 faces, GPU-Z showed 1030Mb, thats 100Mb for a simple 25k object with level 2 subdivision. Since just the render kernel takes over 900Mb if your GPU doesn have tons of vram, add some textures a a couple of subdivided objects and you won't be able to fit it on your GPU. At that moment, every single trick that can help you get your job done gets into play. This is just one of them.

  3. Great tip!
    Is it possible to do the same with light bounces? So that objects that are far away get less light bounces.
    Yes, that would give more noise in these places but when you add depth of field you won't see anything of that.

Leave A Reply

To add a profile picture to your message, register your email address with To protect your email address, create an account on BlenderNation and log in when posting a message.