[MOD] Trees Of Daggerfall

[MasonFace]

My man VMBlast is at it again! Outstanding work!

[VMblast]

Cheers guys. We are all doing this because we want to play awesome Daggerfall!



PS - Ok, Im not near the end, but Im not at the beginning ether. I would like to start testing these models ingame. On that note, I need your help! -Can you tell me how to replace these trees? am willing to do this MOD myself, but I need some specific guldens/tutorials (go there, do this, kind of things). You can PM me if you think this will help streamline the whole thing. Thank you!

//-----------
NOTE - Ok never mind, Ive got it. I think we'll have soon some alpha MOD for testing.

[RolfDew]

First of all, it is amazing that dfunity and it's mods are made by the community! Thank you for the wonderful work! Are the new trees 3d or 2d?

[VMblast]

Are the new trees 3d or 2d?

All the trees and foliage is full 3D.

[Narf the Mouse]

Are the new trees 3d or 2d?

All the trees and foliage is full 3D.

I am kinda worried about how they'll integrate with Tedious Travel, then. :/

[VMblast]

@Narf the Mouse
Yes, Im worried about it as well.


HELP NEEDED
Actually I already encountered huge problem performance wise:
-Ive just added two trees for MOD building testing purposes and what ever I did, how ever I made optimization of the prefabs and assets, performance number always stayed the same.

-However, Ive noticed that the difference between vanila and tree mod is almost the same, except one thing. Option of SAVED BY BATCHING, in the stats tab is increased several thousand fold between mod and vanilla....and I dont know why. Here are screenshots of the problem.

VANILLA



TREE MOD




PS - I dont know what is the problem and Im busting my brains to find/test out. What I know billboards in vanilla are really optimized somehow. However, when I replace them as speedtree material billboards, performance nose dives.

[MasonFace]

Your CPU time more than doubled, which would indicate that the draw calls are bottle necking the rendering pipeline, but your draw calls (SetPass calls) only increased by 10 which should be negligible. The difference is in the number of objects batched.

I think what is happening is that the CPU is getting bogged down trying to figure out what all objects it can batch at run time (dynamic batching). Try setting your tree prefabs to "static" and see if that helps. There may be a reason why you can't but it's worth a shot. That's the only thing I can think of off the top of my head, but I've never worked with SpeedTree assets before. Good luck!

P.S.: Also, look into using GPU instancing on the SpeedTree assets: http://www.procedural-worlds.com/gaia/t ... -unity-55/

https://docs.unity3d.com/Manual/GPUInstancing.html

P.P.S: Upon further reading, I think GPU instancing is enabled on the SpeedTree shader by default, which is probably why the batched count is so high. I think this may not be the issue after all.

I hope I haven't steered you in the wrong direction. Hopefully someone with more direct experience can lend a hand.



.

[VMblast]

Your CPU time more than doubled, which would indicate that the draw calls are bottle necking the rendering pipeline, but your draw calls (SetPass calls) only increased by 10 which should be negligible. The difference is in the number of objects batched.

I think what is happening is that the CPU is getting bogged down trying to figure out what all objects it can batch at run time (dynamic batching). Try setting your tree prefabs to "static" and see if that helps. There may be a reason why you can't but it's worth a shot. That's the only thing I can think of off the top of my head, but I've never worked with SpeedTree assets before. Good luck!

P.S.: Also, look into using GPU instancing on the SpeedTree assets: http://www.procedural-worlds.com/gaia/t ... -unity-55/

https://docs.unity3d.com/Manual/GPUInstancing.html

P.P.S: Upon further reading, I think GPU instancing is enabled on the SpeedTree shader by default, which is probably why the batched count is so high. I think this may not be the issue after all.

I hope I haven't steered you in the wrong direction. Hopefully someone with more direct experience can lend a hand.



.

Thans for all the info. Ive tryed all these suggestions (several times and + shuffling the tweaks), however nothing works. Ive tried literary everything I could come up with (geometry, textures, asset tweaks, LODs, anims....etc) everything,....it just always giving me that insane number of SAVED BY BATCHING number...and performance/FPS is just unusable.

In my other Unity test scene (not DFU), trees run smoothly and flawlessly...really great number of them, just like in that link you've passed. So, my conclusion is Occam razor -if its not models, speedtree, shaders, LODs, anims, tweaks, than it must be something in DFU coding that is causing this nose dive. And Im sure its some small dubious thing to tweak lol.

So unless someone that knows DFU code inside out, step up to help, this MOD is stuck. Its just unplayable...

[MasonFace]

I am kinda worried about how they'll integrate with Tedious Travel, then. :/

Is the concern here the speed that the 3D trees can be instantiated into the scene causing stuttering, or the player colliding with trees and stopping? If its the collision that's the issue, the trees and player can be put on different physics layers and this interaction could be disabled upon fast travel. Once fast travel is disabled, the system can re-enable collision between trees and player, check if the player is currently intersecting a tree, and move the player if needed.

my conclusion is Occam razor -if its not models, speedtree, shaders, LODs, anims, tweaks, than it must be something in DFU coding that is causing this nose dive. And Im sure its some small dubious thing to tweak lol.

Have you changed the shadow settings to see if that has any impact? Nothing in the stats window you showed indicates that it would help, but it's worth a try if you haven't already.

Also, check out the performance profiler. It may be able to give you some deeper insight into where the problem is coming from.

https://docs.unity3d.com/Manual/Profiler.html

[VMblast]

I am kinda worried about how they'll integrate with Tedious Travel, then. :/

Is the concern here the speed that the 3D trees can be instantiated into the scene causing stuttering, or the player colliding with trees and stopping? If its the collision that's the issue, the trees and player can be put on different physics layers and this interaction could be disabled upon fast travel. Once fast travel is disabled, the system can re-enable collision between trees and player, check if the player is currently intersecting a tree, and move the player if needed.

my conclusion is Occam razor -if its not models, speedtree, shaders, LODs, anims, tweaks, than it must be something in DFU coding that is causing this nose dive. And Im sure its some small dubious thing to tweak lol.

Have you changed the shadow settings to see if that has any impact? Nothing in the stats window you showed indicates that it would help, but it's worth a try if you haven't already.

Also, check out the performance profiler. It may be able to give you some deeper insight into where the problem is coming from.

https://docs.unity3d.com/Manual/Profiler.html

Tried it (turn shadows off) and it didnt worked ether (performance was increased, but negligible). Here are the stats (hopefully I captured them ok) -if someone find it useful.
















PS - Now Ive got black screen, for some reason, anytime I load scene. When I press escape, image pop back (with the DF menu), however when I hit escape again to return to game, black screen again (dont know how to fix this thing)....oh god!