Search Unity

Despite NinjaCamp concluding last friday (25/03/11) We still have plenty of projects that were worked on during the week that we’d like to share with you. Starting with a new component: LOD Group


27 replies on “NinjaCamp III: LOD Groups”

[…] Intuitive editor tools for setting and inspecting LODs are included as well as integration into the pipeline to automatically create LODs based on naming conventions. We’re also offering support for fading level of detail transitions using screen-space dithering. Get more information in this blog post. […]

Right now I have 8 LOD levels maximum.

LODGroup currently only interacts with the rendering system. It’s an interesting usecase you have, let me think about it a bit more.

Love the naming standard for automatic LOD’s. That’s very thoughtful of you Joachim. How many levels of LOD are supported? I assume a higher LOD can be triggered, for example, for an explosion effect, swapping out the unbroken model for a broken one and passing the pieces to the physics engine with random velocities…

It already supports a naming convention in the import pipeline :)

In your 3D authoring tool you just name your meshes like this:


This looks awesome, and is just the kind of thing that would help a lot on my current project. We’ve got some LOD middleware scripts but high-performance in-engine support – especially per-camera! – would be killer.

Something to think about (after the first release, methinks) is the asset and authoring side of this – for example, how easy will it be to automatically set up different LOD levels by observing a naming standard for the meshes?

@Joachim Ante

Any possibility of integrating the imposter system? Its fairly similar to LOD – its just a camera render of the object – pasted to a poly quad, and set it to LOD 0 (furtherest away).

It is seperate renderers thus you can listen to the OnBecameVisible / OnBecameInvisible. Essentially the computation is kept internal and is only temporary data so that we can multithread it easily without sideeffects to scripting.

I added QualitySettings.lodBias which can be used for reducing complexity at runtime, fixed drawcall / vert limits are not a very good solution because it just leads to random popping.

I also wondered: Would it be possible to set max Vert Limit or Max Drawcall count limit so that it would show more detailed versions of things on close up but only so far until those limits are reached? Hm, maybe this could also be already adjusted with or be part of bias settings or the platform specific overrides, not sure.

Joachim Ante said on March 29th, 2011 at 2:01 am:

@Zach: LODGroups are only for renderers right now. The reason for this is that LOD is based on the camera and you might have multiple cameras. I can see that a similar feature would be useful for scripts, but it would have to be based on a single point of interest

Hm, wouldn´t both make sense? I could imagine especially for gameObjects/ scripts which are focussed on visual fanciness creation/ running it could be useful to reduce what they do or turn them off completely at certain distance/ size to the camera. For others it may be more useful to turn them on/off / toggle their complexits based on other factors of course (like some AI only running when player is in certain area).

Regarding that i also wondered how one could access the values, would it be properties exposed in GameObject, Renderer or Camera or an own class so one could use/ react to the target LOD in other scripts, too.

Awesome! keep up the good work Unity Team! That’s what I pay you guys for! :D

Just another idea I thought would be neat if you could add to it –
Can you guys add the “imposter” system? eg. When object is far away ( @ LOD 0), the object is replaced by a pre-computed billboard (preferably generated on the fly automatically by the system). For example, let’s say for a tree. It would have 3 LODs, at LOD 3 it would have maximum polygons, while LOD 2 would have 50% less, and at LOD 1 50% less again, and at LOD 0 the system would generate a 2D texture billboard based on the direction of the camera at the time. This technique would speed up the rendering even more!

Great work Joachim. I also love how this Ninja Camp is letting us get to know some of the awesome and very talented people behind UTs magic curtain.

very cool!!! I waited for this! Thank you!

Will it be possible to have one object be subdivided (more polygons) heavily at an area where in example the camera is near at, and not be subidivded at all where the camera is not near at (For very large objects such as whole planets in example) ? So basically this would allow any object to take over the efficient LOD of terrains, but without the terrain editor possibilities (trees, heights,..) and without its limitations (not turnable, ie). Would just love it!

I worked on this to do myself but it didn’t go that well :P Very impressed with what you guys do and how you do it! Thanks again, and hope it will be implemented soon :)

@Jonathan: Haven’t worked on lightmapping integration yet. The idea is that lightmaps get shared between LOD levels. Need to figure out how. Alternatively having every lod level receive seperate lightmaps, is also possible but usually less efficient. In the case of automatic UV generation that is probably hard to match up exactly. So maybe i’ll add an option for it. I’ll play around with it, see what happens.

@Zach: LODGroups are only for renderers right now. The reason for this is that LOD is based on the camera and you might have multiple cameras. I can see that a similar feature would be useful for scripts, but it would have to be based on a single point of interest.

Really cool feature! Could this also be extended to work with entire gameobjects also? For example you could define 3 LOD gameobjects that decrease in complexity the further away you are. Each level would then strip away specific scripts/meshes etc

LODGroups work with any renderer type. So you can use it with Skinned meshes, Cloth Renderer, LineRenderer, Particle systems or Mesh Renderers.

We’ll definately include a system wide LOD bias.

If I have extra time, i also want to add some platform overrides, so we can strip out the highest LOD levels at build time on mobile etc.

Fantastic! This one has really been missing in Unity up to now!
(Yes, I know we all do it in script code – but this is probably much more efficient)

Please include a system wide LOD BIAS value that we can play around with. So that we can setup prefabs with screen pixel size values that are optimized for a “normal” system. And then we can adjust the LOD BIAS to handle more powerful or less powerful systems, without changing the pixel size values in all models :)
So while a regular PC might use a LOD BIAS of 1.0, while a mobile might build might use a much higher BIAS. Or – just to handle the difference in pixel size between a regular and a retina display – just increase the LOD BIAS by 200%.

Can’t wait to see this in the next version of Unity!

@JoeW: The way I would expose it is by allowing shaders to be tagged with “SupportsLODCrossFade” in which case they can use a builtin shader property and we would then render both meshes during the transition.

The most common use these days is to use crossfade screendoor dithering with alpha test. Alphablending has a bunch of problems especially in deferred rendering. That said, in practice most games these days do no cross fade at all, for various reasons.

Are there plans to add any kind of cross-fade tolerance? I know that may not seem needed given the example, but if you are using objects that have a lot of difference between their low and high-poly versions, a cross-fade can avoid visual “popping” which can become annoying in complex scenes.

Regardless of whether that’s in the works or not, this is a GREAT new feature – very useful.

Cool – this looks like an awesome feature that Unity has been missing all along. Thanks for sharing that you’re planning to officially add this to Unity “someday soon” (like, “kind of probably” ;-) ) – I had thought of creating my own LOD system but I guess that’s no longer necessary (and something that’s integrated right into Unity can obviously be much more optimized than something added via scripting).

NinjaCamp FTW!!! ;-)

Comments are closed.