Trees Of Daggerfall [PERFORMANCE PROBLEM/SOLUTIONS]

Discuss modding questions and implementation details.
User avatar
VMblast
Posts: 502
Joined: Wed Mar 29, 2017 12:22 pm
Contact:

Re: Trees Of Daggerfall [PERFORMANCE PROBLEM/SOLUTIONS]

Post by VMblast » Fri Sep 06, 2019 8:06 pm

@MasonFace
That is true. However what Ive meant is that draw distance only in this particular situation, is the problem. But my aim for the culprit is that its something about SPTree billboards (mesh and or shader) is the problem (or both). Big problem also is that SPTree doesent give any way of tweaking billboards (except how many sides can they have -and lowest number is 4), in the software alone.

My only solution (as Ive mentioned before) is to do custom billboard shader, in which we have to use big texture atlas, for the entire zone (tree zone). This way it would be made quite similar to the vanilla DU billboards. Down side is that each tree would have just one viewing side, atm billboards have about 8.

User avatar
MasonFace
Posts: 334
Joined: Tue Nov 27, 2018 7:28 pm
Contact:

Re: Trees Of Daggerfall [PERFORMANCE PROBLEM/SOLUTIONS]

Post by MasonFace » Fri Sep 06, 2019 9:05 pm

I did a quick test last week where I replaced the billboard LOD with a simple billboard shader and set all of the billboards to use the same texture. Performance wise, it should have produced the same effect as what you described since they all share the same texture/material, they should get batched. But that's kind of the problem... this dynamic batching is sucking major CPU time just to save some draw calls.

The reason that the DFU billboard shader is so efficient is that it combines all the tree billboards into one mesh. Each of the quads that the trees are drawn onto are billboarded (its orientation changed to face the player) by the shader using the GPU, so no involvement of the CPU. All the CPU has to do is send instructions on how to render the combined mesh of all the trees. Very few draw calls, next to no batching. The trees are just one object. The CPU spends its time telling the GPU how to renderer the trees as a singular collective object instead of wasting its time instructing how the GPU should render this one, then this other one, then this other one, then this other, etc...

The downside to this is I believe you cannot use LODs or culling since the combined mesh is all the trees. They can either all be on, or all be off. Nothing in between. So when you play vanilla DFU, all the trees of a terrain chunk are rendered, unless you are looking straight up or maybe down to where none of the combined meshes are in the view frustum. Like I've said before, this takes the load off the CPU and puts it onto the GPU, but most modern GPUs can handle vanilla DFU billboarded trees in the thousands without breaking a sweat so this isn't an issue. Most modern GPUs however can't handle thousands of tree meshes at the same time, so the combining meshes trick is kind of out the question there. Too many polygons to combine anyhow.

I predict that if you replace the LOD0 meshs with a billboarded sprite and don't alter the distance to which they stop rendering, there will be a nearly trivial gain in performance because it still takes nearly as much CPU time to batch all the billboards as it would to batch billboards + meshes. You'd save a little bit because the meshes have multiple materials whereas the billboards do not, but the CPU time savings would still be quite minor.
My only solution (as Ive mentioned before) is to do custom billboard shader, in which we have to use big texture atlas, for the entire zone (tree zone). This way it would be made quite similar to the vanilla DU billboards. Down side is that each tree would have just one viewing side, atm billboards have about 8.
I had been interpreting this to mean that we simply replace the SpeedTree billboard shader with a custom shader that does mostly the same thing and keep the mesh LOD0. Are you saying that we should scrap the LOD system and replace it with 8 view billboard sprites? If so, I can get behind that. But again, I think it will only help if we combine the billboard meshes like how InterKarma did.

Without scrapping the LOD system, we can't combine meshes. If we can't combine meshes, then we must rely on dynamic batching. If we rely on dynamic batches, CPU is going to get choked.

User avatar
VMblast
Posts: 502
Joined: Wed Mar 29, 2017 12:22 pm
Contact:

Re: Trees Of Daggerfall [PERFORMANCE PROBLEM/SOLUTIONS]

Post by VMblast » Mon Sep 09, 2019 12:26 pm

MasonFace wrote:
Fri Sep 06, 2019 9:05 pm
I had been interpreting this to mean that we simply replace the SpeedTree billboard shader with a custom shader that does mostly the same thing and keep the mesh LOD0. Are you saying that we should scrap the LOD system and replace it with 8 view billboard sprites? If so, I can get behind that. But again, I think it will only help if we combine the billboard meshes like how InterKarma did.

Without scrapping the LOD system, we can't combine meshes. If we can't combine meshes, then we must rely on dynamic batching. If we rely on dynamic batches, CPU is going to get choked.
To be honest I dont know, but what is obvious to me at least is that we have to try that path as well. To scrap sptree LOD system and replace it with something that works and it is optimized well.
(Unless you want to do that Octahedral imposter solution) :P
https://hal.inria.fr/hal-00650120/file/article.pdf

User avatar
Hazelnut
Posts: 1502
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Re: Trees Of Daggerfall [PERFORMANCE PROBLEM/SOLUTIONS]

Post by Hazelnut » Mon Sep 09, 2019 12:42 pm

Sorry if this is a stupid question, I've not managed to follow all of the discussions on here. Why can't speedtree just be used for the nearest terrains (terrain dist = 1) and the standard DFU batched billboards used for more distant terrains? It would need the 3d trees to match the sprites or new sprites matching the 3d trees, but that should be doable.

User avatar
VMblast
Posts: 502
Joined: Wed Mar 29, 2017 12:22 pm
Contact:

Re: Trees Of Daggerfall [PERFORMANCE PROBLEM/SOLUTIONS]

Post by VMblast » Mon Sep 09, 2019 12:53 pm

Hazelnut wrote:
Mon Sep 09, 2019 12:42 pm
Sorry if this is a stupid question, I've not managed to follow all of the discussions on here. Why can't speedtree just be used for the nearest terrains (terrain dist = 1) and the standard DFU batched billboards used for more distant terrains? It would need the 3d trees to match the sprites or new sprites matching the 3d trees, but that should be doable.
Actually that was something I was proposing the entire time, as one of the solutions. I just dont know to do it, Im not coder and it seems to me that it has some fair coding work on it. :P

Problem till now was the naming. To replace DU original billboards you have to, as you know, name it the same. It does the work and it replaces the DU vanilla textures with 3D models...however you cant have both in the same time. If you are interested with this solution, please give it a go. :)

PS - I can export the 2D image of the same 3D tree, which can be used as a replacement of DU vanilla graphics. However what to do with 3D forground element than and how to leave it on Terrain1 distance.

User avatar
Ferital
Posts: 154
Joined: Thu Apr 05, 2018 8:01 am

Re: Trees Of Daggerfall [PERFORMANCE PROBLEM/SOLUTIONS]

Post by Ferital » Mon Sep 09, 2019 12:58 pm

VMblast wrote:
Mon Sep 09, 2019 12:26 pm
To be honest I dont know, but what is obvious to me at least is that we have to try that path as well. To scrap sptree LOD system and replace it with something that works and it is optimized well.
(Unless you want to do that Octahedral imposter solution) :P
https://hal.inria.fr/hal-00650120/file/article.pdf
Bruneton's work is awesome. I discovered it years ago (around 2011-2012). At that time his Proland demo was too power hungry for my ~2008 CPU/GPU, I guess it should work fine on modern rigs. It didn't age that much by the way.



Some source codes (including beautiful ocean shaders) available here if someone is interesting for using this in a DFU mod: http://www-evasion.imag.fr/Membres/Eric.Bruneton/#demos
Last edited by Ferital on Tue Sep 10, 2019 7:55 am, edited 1 time in total.

User avatar
Hazelnut
Posts: 1502
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Re: Trees Of Daggerfall [PERFORMANCE PROBLEM/SOLUTIONS]

Post by Hazelnut » Mon Sep 09, 2019 1:19 pm

VMblast wrote:
Mon Sep 09, 2019 12:53 pm
Hazelnut wrote:
Mon Sep 09, 2019 12:42 pm
Sorry if this is a stupid question, I've not managed to follow all of the discussions on here. Why can't speedtree just be used for the nearest terrains (terrain dist = 1) and the standard DFU batched billboards used for more distant terrains? It would need the 3d trees to match the sprites or new sprites matching the 3d trees, but that should be doable.
Actually that was something I was proposing the entire time, as one of the solutions. I just dont know to do it, Im not coder and it seems to me that it has some fair coding work on it. :P

Problem till now was the naming. To replace DU original billboards you have to, as you know, name it the same. It does the work and it replaces the DU vanilla textures with 3D models...however you cant have both in the same time. If you are interested with this solution, please give it a go. :)

PS - I can export the 2D image of the same 3D tree, which can be used as a replacement of DU vanilla graphics. However what to do with 3D forground element than and how to leave it on Terrain1 distance.
I might play with this, but wont be for a couple of weeks at least as I'm away. I worked very closely with this part of DFU code when I did some performance work so I think it's possible, but yeah it's not possible with current asset replacement facilities - it will need some more integration than that. Is there any way to get 3d trees that match the existing sprites, or is the only sensible way to replace std sprites with new 2d images of the speedtrees?

User avatar
VMblast
Posts: 502
Joined: Wed Mar 29, 2017 12:22 pm
Contact:

Re: Trees Of Daggerfall [PERFORMANCE PROBLEM/SOLUTIONS]

Post by VMblast » Mon Sep 09, 2019 1:48 pm

Hazelnut wrote:
Mon Sep 09, 2019 1:19 pm
I might play with this, but wont be for a couple of weeks at least as I'm away. I worked very closely with this part of DFU code when I did some performance work so I think it's possible, but yeah it's not possible with current asset replacement facilities - it will need some more integration than that. Is there any way to get 3d trees that match the existing sprites, or is the only sensible way to replace std sprites with new 2d images of the speedtrees?
Ive made 3D trees as closest to the original graphics as possible, so there is no more room for wiggle. As I see it, it would be better to replace sprites with the new images of the sptree's. Simply it gives more creative room for any future contributors, that may wish to do some other tree design.

User avatar
Hazelnut
Posts: 1502
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Re: Trees Of Daggerfall [PERFORMANCE PROBLEM/SOLUTIONS]

Post by Hazelnut » Mon Sep 09, 2019 9:48 pm

Well replacing sprites with new versions of the trees will be down to the modder. My plan is to set up a system where mods can provide 3d models and 2d textures to replace each nature thingy (i.e. tree) based on the archive/record just like it is now. The only difference is that nature flats will only replace with 3d model when the terrain chunk (i.e. 1 df map pixel square) is the one the player is in or an immediate neighbour. This could be made configurable so players can set terrain distance & model replacement distance if there ever seems value in doing so, but for now I will work with a distance of 1. Beyond that distance, the standard batched billboards of DFU will be used, and the texture will either be a replacement or the default if none is found.

I've hacked together a proof of concept prototype of this tonight and it seems to work fine. :D

Here are some pictures, first at a terrain boundary in the editor with models on left and flats on the right. I was playing the game - this is scene view with game paused.
3dBillboardTrans.png
3dBillboardTrans.png (1.7 MiB) Viewed 129 times
Next is a distance view while levitating with the fog switched off so the terrain can be seen in the distance. (usually the fog covers up the hard terrain end) I think this proves that the models don't have to match exactly since the distance the flats will be seen from they'll only be a few pixels high. This is with view distance of 4 and the models stop around where the water is on the left. It would look much better with a less agressive LOD for the trees since only the ones in immediate foreground are 3d, others a SpeedTree billboards I think.
distanceView.jpg
distanceView.jpg (1.14 MiB) Viewed 126 times
Pretty happy I proved it can be done anyway :D . I walked accross a few pixels and back with no issues. Main issue is optimisation - this prototype just brute forces it all as I was in a rush. Unfortunately doing a proper implementation will need to wait a couple of weeks as I will be away from home. Just wanted to share this with you in the meantime.

I'd like to try this with trees with much reduced LOD or even no LOD and see how well it works. Worth seeing if not using SpeedTree billboards at all is feasible. I definitely think the current release is way too agressive and as you walk the LOD changes are really noticable. That's a task for you VMBlast. If you tune it to be balanced for view dist 1, possibly have a high and low spec release or a setting (no idea if that is possible) and I'll ensure that beyond dist of 1 normal batched billboards are used. :ugeek:

User avatar
Hazelnut
Posts: 1502
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Re: Trees Of Daggerfall [PERFORMANCE PROBLEM/SOLUTIONS]

Post by Hazelnut » Mon Sep 09, 2019 10:08 pm

Another nice view with normal distance fog.
niceView.jpg
niceView.jpg (1.01 MiB) Viewed 122 times

Post Reply