Trees Of Daggerfall [PERFORMANCE PROBLEM/SOLUTIONS]

[VMblast]

By @Interkarma suggestion I am opening this topic, because I am stuck with this issue and also because two (and more) heads are smarter than one.

PROBLEM:
3D trees MOD replacement have huge performance (CPU) hit, especially over terrain distance (patch) of 1. Main issue lies probably in billboards draw and its relation to the DU.

Ill be frank here and say that if we do not find solution to this problem, there will be no way of using any kind of 3D trees as an MOD replacement in the future (so not just my mod work). I will post here one of the trees models in unity (unity prefab / sptree). If you make a mod for just this one tree and import it in DU, you'll immediately see performance drop. Why is this happening...I havent got a clue. Everything suggests that it has to work really well, as it is using SPTree billboard shader (and sptree billboard batching). However, the DU billboard batching, as @Interkarma made it, is insanely performant. The goal is to reach this kind of performance for the 3D trees billboard LOD level.

If anyone needs couple of more trees for testing in Unity, let me know and Ill try to export them as well.

DOWNLOAD:
https://drive.google.com/open?id=1kvIHc ... N141-mTxH_

[ShortBeard]

My immediate first thought with the 3D tree lag problem is doing the old trick of making the world "foggy" so that the draw distance is limited. That way all tree geometry beyond the fog can be culled and only popped in as the distance becomes close enough.

I don't think that's a permanent solution though as people want to be able to see a long draw distance, that being one of the main draws of DFUnity. I'm not sure if there's some kind of occlusion culling in place, but that might be another route to look at as well. Just throwing out some ideas!

[VMblast]

@ShortBeard
Thank you for the idea (and interest in this topic). Ive already written about that in the first page for the released MOD. Any terrain distance setting other than 1, will cause your computer to..."HALT!"... That first setting of -terrain distance 1- will make it work, but you'll feel it. Frame rate will be much lower than with vanilla DU billboard batching.

People just love to see their distance cranked up to max and to be fair so do I.

[ShortBeard]

One thing worth noting is that if you run the Trees of Daggerfall mod from within Unity, and then turn off some of the surrounding terrain GameObjects that the player isn't even looking at, there is a considerable FPS improvement. Now, I'm not sure if this FPS improvement comes from the fact that the editor itself is dealing with less overhead in the editor, or if the game itself has to "render" less, or a mixture of both. So it might be worth considering attempting some kind of mod or addition to DF trees like "Only have terrain game objects activated for terrain that is near the player or that the player is facing towards". Or getting the terrain that falls within the players camera frustum. Just an idea!

Before terrain de-activated - Around 35fps
After terrain de-activated - Around 70fps
Note that from the point of view from the player in the game, nothing has changed. However, this might get more tricky when dealing with hills and mountain areas.

before_delete.PNG (267.63 KiB) Viewed 486 times

after_deletion.PNG (98.46 KiB) Viewed 486 times

[VMblast]

@ShortBeard
As Ive mentioned before, Terrain Distance 1 setting isnt that big problem. On my rig (ryzen 5 12c, 16Gb, 1050TI) I get around of 40fps and it looks something like this:







So its not that big of a deal, it can be still played somewhat decent. However it is a huge hit in compare to the DU Billboard Batching - sptree billboards (script and shader) cannot compare to it. Ive also pushed billboards transition as closest to the camera/player as I could, which increased performance, but that was just not enough.

I had two ideas as a possible solution:
-To switch back to the DU billboard batch, after 3D models LOD culling.
-To make custom billboard batch script from ground up, which will work with 3D object LOD system and make a good bridge to DU structure.

[King of Worms]

"To switch back to the DU billboard batch, after 3D models LOD culling."

Hi, this might work nicely, because if it works as fast as it should, than the 3D tree distance can be increased a lot (now its quite short because of performance reasons) so the switch to 2d will be happening in a distance, thus being less distracting

On the other hand, u need to keep the 3D stuff vanilla, esp in the terms of size. Ive noticed that for example the two fallen branches crossed is MUCH bigger in your mod than in vanilla. That will cause problems in this case.

I think this might be the most easy way to start things uú? Worth a try?

PS: So yea, my guess is that the performance hit is MOSTLY caused by the 1000s of billboards in the distance, and not the actual 3d trees themselves. Because so far, replacing the billboards with 3d models works smoothly in other mods.

[Siwone]

The first thing that comes to mind would be occlusion culling. Taking a quick peek in the editor with the Overdraw mode for the scene view selected should visualize if there's a lot of overdraw happening in which case occlusion culling would likely greatly help performance. From what I can see, basic DFU trees don't have any overdraw (due to the batching?) but the towns have quite a bit (potential for future optimization).

There's also something called GPU Instancing which would allow efficient rendering of multiple copies of the same 3d model. I'm not familiar with this technique myself but it would certainly be something to look into.

Now I am not quite sure how the trees in the mod work but it sounds like the 3d models are replaced by billboards as LOD changes? Are those billboards perhaps generated at runtime? If that's the case that could definitely be a big performance hit.

[Dalebvr]

Speaking as a user of Vue Infinite for several years, the billboard density is outright murder on both framerate and raytracing. Even an optimized render engine and instancing for animation requires clever placement of occlusion to keep rendering speeds from outright stalling due to light calculations. Even after several iterations of Vue, they haven't quite managed to squash the render bug that results from the rays through the multiple billboards creating either shadow artifacts or floating point calculations that could push frame render up to 12 hours per frame or more. There are times I've had to outright disable tracing and go with pre calc lightmaps to get an animation sequence completed.

Maybe if Unity implemented the realtime raytrace that the latest GPU's support, that could bypass a lot of that issue, but from all the discussions I've been in on with people sure that gaming renderers could easily supplant purpose built renderers, and the results of nearly all of them (ie: game engines are designed from the ground up to cheat their way to a simulation of reality, not chew through the math needed to actually simulate it), I think the only thing that will ultimately solve the framerate issue is reducing the depth of the viewing field. Unless there was some way to selectively set the billboard depth so that after distance X, they don't react to lighting as the closer boards do.

[MasonFace]

Just to be clear, this thread is a continuation of this discussion, particularly page 5 and later.

@Siwone:

The first thing that comes to mind would be occlusion culling.

I agree. From the rendering stats, the CPU time goes up significantly, yet the set pass calls are about the same. The only other thing the CPU should be doing (with regards to these assets) is batching and culling. So what's bogging it down? To me, it must be the culling calculations. In particular, SpeedTree requires the tree prefabs to be instantiated a special way so that it can cull an entire unit area (called a cell) efficiently. I don't think DFU asset injection respects this special instantiation so the occlusion culling is broken for SpeedTrees. Mentioned here.

There's also something called GPU Instancing which would allow efficient rendering of multiple copies of the same 3d model. I'm not familiar with this technique myself but it would certainly be something to look into.

SpeedTree's shader already uses GPU instansing. Source

Now I am not quite sure how the trees in the mod work but it sounds like the 3d models are replaced by billboards as LOD changes?

Correct.

Are those billboards perhaps generated at runtime?performance hit.

No, the billboards are baked into a texture atlas beforehand.

@Dalebvr:

If I understand your reply, it seems like you are suggesting that the performance hit could be from excessive lighting calculations. I can say from the performance stats I've seen that there seems to be no major difference in the render thread, so I see no reason so suspect that lighting calculations are the culprit.

I don't mean to downplay your experience with raytracing, but we're working exclusively in the domain of rasterization at the moment. However, your experience will certainly come in handy for when raytracing is more relevant to DFU.

[MasonFace]

I'm wanting to do some experiments once I get some time, but I wanted to post it here in case anyone else has a chance to get to it before I do.

Theory:
As I mentioned before, I'm about 75% sure that the performance problem is due to SpeedTree API's special culling system. The suggestions of Distant Terrain = 1, making the LODs very near the player, and adding fog (distance culling) are merely slapping band-aids on the problem. They help the performance by manually culling the objects before SpeedTree gets bogged down trying to cull them itself.

The reason I believe this is the root cause of the issue is due to the performance stats indicating that the CPU time is increasing with SpeedTree, yet I'm not aware of other Unity projects' performance suffering this badly from using SpeedTree assets, even with much much higher tree densities than this. It seems very likely to me that DFU world streaming system isn't setup to handle SpeedTree's culling system. I believe this explains the longer than expected initialization times and higher CPU cycles.

From my understanding, if you were to build a static scene in Unity, and populate a terrain with SpeedTree assets, then it will automatically populate the occlusion cells properly. However, we are streaming the world and its contents dynamically in DFU. If these SpeedTree assets aren't manually populated into its cell structure the right way, then the SpeedTree system struggles to make sense of the culling information and thus performance tanks.

Solutions:

1. In my view, the proper fix would be to fix the SpeedTree instantiation to conform to the SpeedTree's API, but I think that would be a lot of effort and I doubt it's the best use of TheLacus's time.
2. I think the SpeedTree shader is barring you from using the Daggerfall Billboard Batch shader in your LOD. Seems like I had a similar problem once before on another Unity project. I think SpeedTree is very particular with what you use in the LODs since it uses a dithering cross fade effect to blend between them. As an intermediate solution (still a band-aid) You may want to just try to disable the "animate cross-fade" option and see if it will allow you to use the DF Billboard Batch shader in your LOD before you go any further.
3. Perhaps the most direct solution is to simply not use SpeedTree. If we can isolate just the tree mesh and build a traditional Unity LOD group, then it would bypass the (theoretical) culling issues with SpeedTree and allow us to use the DFU Billboard Batch shader to get the best performance. The 3D models and billboards would be culled in the traditional way without relying on SpeedTree's "cells" being setup a particular way, so it won't be as fast as a proper SpeedTree implementation, but should be radically faster than it is now.

It would be this weekend at the very earliest before I could begin any testing so if anyone wants to give it a try before me, go for it!