Add support for props to skip the automatic computation of LODs

[Basilisk3]

Description of the proposed changes

As per the title. Currently, all props have their blueprint-defined LOD values overridden. This is good because it allows us to test and implement sweeping changes with relatively little work. However, in some cases, a bit more control is desired, e.g., when certain LOD levels are meant to be displayed for longer. This PR adds this option via the introduction of the USEBLUEPRINTLOD category, which enables a prop's blueprint values to take precedence again. I imagine this could also be useful for mod authors in cases where they want to exclude some props from the automatic computation.

At the moment, no props have this category. I will create a separate PR to fine-tune the individual LOD values of certain props in the near future. The goal is to preserve the improvements Jip made while reverting the distance at which the VertexNormal of certain props is displayed to its previous value. From what I can tell, this is possible.

Checklist

• Changes are annotated, including comments where useful
• Changes are documented in a changelog snippet according to the guidelines.
• Request 2-3 reviewers from the list of reviewers and their areas of knowledge.

[BlackYps]

I'm not sure if this is going in a direction that is helpful to address the root problem. In theory the changing of LOD levels should ideally be barely noticeable to the user. When the lowest level looks better than the level before that, then we should investigate there.

[Basilisk3]

I'm not sure if this is going in a direction that is helpful to address the root problem.

@BlackYps This PR is designed to only give us an additional knob to play with. Right now, the blueprint values are skipped entirely, but I think it would be beneficial to at least have the option for blueprint values to take precedence, if desired.

In theory the changing of LOD levels should ideally be barely noticeable to the user. When the lowest level looks better than the level before that, then we should investigate there.

After some additional testing and further contemplation, I think the way the second LOD looks is fine, and the issue is that it’s currently being used at too-high zoom levels. I addressed this in my other PR.

This is the maximum zoom level at which the second LOD level is currently visible:

As you can see, tree groups are more difficult to identify, and the overall look feels a bit out of place.

Displaying the most detailed LOD level for longer

You made the suggestion, that the second, less detailed LOD level could be removed entirely. I found the idea intriguing, so I tested it.

With the second LOD level retained:

With the second LOD level removed:

Visually, I prefer the first screenshot (with the second LOD level retained). Removing it, however, eliminates the transition between the LOD levels, which looks smoother and more modern - albeit with a potential performance cost that still needs to be investigated.

In summary, I think a good argument can be made for both keeping and removing the second LOD. I would prefer to keep it for now and make the LOD behavior more similar to how it was pre-patch, while retaining the increased maximum render distance of trees (which is what I am doing here and in #6907).

[Garanas]

If the goal is to prefer showing higher LODs sooner then you can also adjust the formula found here:

fa/lua/system/blueprints-props.lua

Lines 115 to 137 in 3bad1c4

	-- give more emphasis to the x / z value as that is easier to see in the average camera angle
	local weighted = 0.40 * sx + 0.2 * sy + 0.4 * sz
	if prop.ScriptClass == 'Tree' or prop.ScriptClass == 'TreeGroup' then
	weighted = 10.0
	end
	-- https://www.desmos.com/calculator (0.9 * sqrt(100 * 500 * x))
	local lod = 0.9 * MathSqrt(100 * 500 * weighted)
	if prop.Display and prop.Display.Mesh and prop.Display.Mesh.LODs then
	local n = TableGetn(prop.Display.Mesh.LODs)
	for k = 1, n do
	local data = prop.Display.Mesh.LODs[k]
	-- https://www.desmos.com/calculator (x * x)
	local factor = (k / n) * (k / n)
	local LODCutoff = factor * lod
	-- sanitize the value
	data.LODCutoff = MathFloor(LODCutoff / 10 + 1) * 10
	end
	end
	end

If you change local factor = (k / n) * (k / n) to local factor = (k / n) * (k / n) * (k / n) it will preference the higher LODs while the maximum render distance remains unchanged. Additionally, you can change add 10 to the sanitized result. As an example:

INFO: /env/redrocks/props/trees/groups/redtree01_group1_prop.bp	LOD:	1	4.3744492530823	 -> 	1.4581497907639
INFO: /env/redrocks/props/trees/groups/redtree01_group1_prop.bp	LOD:	2	69.991188049316	 -> 	46.660793304443
INFO: /env/redrocks/props/trees/groups/redtree01_group1_prop.bp	LOD:	3	354.3303527832	 -> 	354.3303527832

INFO: /env/evergreen/props/trees/groups/pine06_big_groupb_prop.bp	LOD:	1	6.8673510551453	 -> 	2.2891170978546
INFO: /env/evergreen/props/trees/groups/pine06_big_groupb_prop.bp	LOD:	2	109.87761688232	 -> 	73.251747131348
INFO: /env/evergreen/props/trees/groups/pine06_big_groupb_prop.bp	LOD:	3	556.25537109375	 -> 	556.25537109375

Looking at these results it may also be interesting to add a flat value of 10 to each level. Because a LODCutoff of 4.3 won't show up any time soon, let alone 1.45 😃 !

[Basilisk3]

@Garanas Good catch, local factor = (k / n) * (k / n) * (k / n) was the first thing I tried when making the PR, but thanks for steering me back toward the correct solution anyway. I tried local factor = (k / n) * (k / n) * (k / n) * (k / n) now, and it reverts the starting zoom level for the least detailed LOD back to how it was pre-patch. Since this is a more aggressive formula, I also went with adding a flat value of 30 instead of 10.

It looks promising on Seton's, but I haven't tested very many other maps yet. I think red maps still need some tuning, the most detailed LOD of a lot of the trees there is still not visible for very long.

@Rhaelya Can you give these changes a try to see if this does what you are looking for? I did some preliminary testing on Seton's, and I think this is the outcome we're after. You won't need the changes from #6907 to test the new LOD levels now.

[Basilisk3]

I did some more testing on a variety of maps, and found no glaring issues. If the skip the automatic computation of LOD part of the PR isn't liked, I'll revert it. I think it's a fine idea but not essential.

@BlackYps Since you are more experienced than I am, can you take another look at this?