In some situations it’s neccesary to set mesh LOD’s based on distance rather than screen size. Some of the meshes I’m using for this are much larger than can fit on the screen (weather planes) - and LOD 1 screen size is always clamped to 1.0.
In my case the screen size is useless anyway because it’s completely different in-editor to what it is when deployed to a device or when running standalone. Please bring back support for setting LOD’s based on Distance, it’s 10x more intuitive and in some cases makes much more sense.
Another issue caused by the screen-space LODS, is that items are LOD’d based on how much of the screen they take up - so when objects are semi-occluded this also causes problems. In the case of meshes that are supposed to be larger than the screen or are often occluded, this system really doesn’t work.
Bonus points available here for being able to constrain the distance to a plane. E.g. in my case, I only care about the XY-distance, not the Z-distance.
My only option now is to do a fancy vertex-shader, which collapses the mesh when the camera is a certain distance from it to prevent all the overdraw. This requires extra UV sets and vertex colours (which AFAIK are imcompatible with foliage).
It’s a lot of manual work to set LOD swap distance based on screen space atm. It take a lot of good testing for every mesh. But if it was based on distance from player that’d save a lot of hassle for me personally since I’m dealing with lots of meshes of any size.
In case it helps anybody, I was able to develop a workaround for my use-case - but of course this won’t work for everybody.
My issue was that I have a series of transparent planes used throughout the level, used for rain / snow etc. As the player moves further away, I needed to decrease the density of the planes to prevent ‘copious overdraw’ and stupid levles of shader complexity. Splitting up the rain mesh and painting different vertex colours of on some of the planes allows me to mask them off based on distance in the shader itself. The following goes inot ‘World Position Offset’.
Of course this really only works for my use case, but if someone else is doing something similar this might be useful. It doesn’t prevent sending the vertices to the GPU of course, so they are still processed - but it does save on pixel shader time. Could probably make this more efficient too.
While I appreciate that you guys look into the feature request, I think it’s a big mistake to make things happening or not happening based on votes. Looking at the number of votes on the UE4 Roadmap it’s clear only a fraction of people who need something get to vote for it. For example maybe 20 people vote for TAA improvement if there was a ticket and then it’s considered low priority based on the number of votes where the actual audience affected by that are almost “anybody” using UE4 but they never actually look for a place they can vote. I had a petition put up for Real-Time GI and despite the good exposure I gave it on all social medias it received only 41 votes. Votes truly do not determine the community interest.
If that is the general consensus, then we can look at doing away with voting on things and see about what would be a more accurate way to determine where the community would benefit. I’m always interested in hearing feedback about how we can better focus our efforts.
You can see 9 people in this thread but only 4 votes on the ticket. I don’t have a quite accurate solution but I think it’s better you make a manual judgement according to the number of people, posts and threads involved regarding a common issue and give it an appropriate priority lable instead of putting up a vote system.
I’ve made the other ticket public. It’s not a typical ticket, though, as it was more of a task that was logged as a “bug” ticket. So this outline and style of this ticket will vary compared to others that we have for New Features or Bugs that have been reported.
In 4.15 we have refactored how LODs are handled to be more consistent across Static Meshes, Skeletal Meshes, and HLODs. Keep an eye for more details about this in a future release.
Thanks! But are you sure that UE-34057 is a duplicate of UE-35028? I only see UE-35028 as being a ticket about consolidating the use of screen size, but not a feature for being able to calculate LOD based on distance and not screen size, so isn’t UE-34057 about something else?
Sorry for the confusion. I added another comment to the original ticket. Essentially, the LOD by distance is not a feature that we’ll add, but the other ticket I made public should resolve most issues that people run into with inconsistencies and LODs.
Originally LOD by distance was in very early versions of UE4 (4.1 or 4.2) before it was replaced with screensize. You do have the option to go back and look at the source there to implement your own method based off that if what we provide does not align with development of your project(s).