I’m having a crash whenever I enable Tessellation on a material that is applied to a mesh which is being used as foliage. aka, if I enable tessellation into my tree trunk material.
A few more info:
My tree is a speedtree asset, and I tried with and without the SpeedTree node applied into WPO, the crash is the same.
So far I only tried with FlatTriangles tessellation.
This happens in 4.11 Preview7, but I’m certain this happened in 4.10 as well.
I run with a GeForce GTX 970, driver version 361.75 which is from Jan’27 2016. Next up I will try to update my drivers to the latest version (currently there’s 362.00 available)
The crash happens if I have trees placed as foliage and then enable tessellation in the material.
I also tried applying tessellation first (which works fine if the tree is placed as a StaticMeshActor), and only then painting foliage. as soon as I click to paint the foliage I get the crash.
The crash behavior is different than usual UE4 crashes. This one freezes the entire PC for a couple of seconds, I get a popup saying that the Video Driver crashed, and I also get a windows notification message saying that the Video Adapter crashes and then recovered successfully.
One of the times I actually got the UE4 crash reporter window. this is the full summary information (yes shorter than usual)
Fatal error:
[File:D:\BuildFarm\buildmachine_++UE4+Release-4.11\Engine\Source\Runtime\Windows\D3D11RHI\Private\Windows\WindowsD3D11Device.cpp]
[Line: 419] The Direct3D 11 device
that was being used has been removed
(Error: -2005270522 ‘HUNG’). Please
restart the game.
Does this occur in a clean, blank project with no additional content or is it limited to one project?
Can you post your crash logs here so I can take a look? These can be found at \Unreal Projects\PROJECTNAME\saved\logs.
If you get the crash again, can you send the crash report so we can look it up in our crash report software?
Does this occur with simple meshes? For instance, if you take a simple cube and apply a material with tessellation to it, do you still get the same crash?
Have you tried this in 4.10.4 to see if it is occurring in a non-preview version?
Can you post your dxdiag here so I can have a look?
What are the exact steps I can take to reproduce this on my end?
How are you spawning the foliage actors? Are you using the foliage tools or the Procedural Foliage Volume?
I’ve investigated some more and almost isolated the issue.
Answers to some of your questions:
The issue also occurs in a clean, blank project
The issue also occurs in 4.10.4
I’m spawning the foliage via manual painting with the foliage tools
Some new info I found:
Reducing my material complexity made the issue not be a crash anymore, now I just get 3 FPS. Thing is I had both POM and tessellation for testing purposes
The issue only occurs when using WorldDisplacement. Using only Tessellation alone works properly.
Displaying the viewport in Unlit or making my DirectionalLight not cast shadows makes the issue not occur
In my own project, using or not using the VertexNormalWS node going to WorldDisplacement, was what would cause or get rid of the issue
By trying to isolate the problem further I lost the part that broke it so I have to retrace.
Sadly atm I don’t have proper repro steps. I made a copy of my stuff into a 4.10.4 project and started deleting stuff from there instead of ‘building it up’
All the info from my previous posts is still relevant. Here’s the final additional info:
The issue only happens with SpeedTree tree meshes, but not on other meshes (tried the cube with the same material).
Happens all the same if imported the tree with the option ‘Individual Meshes’ or ‘Foliage’
The issue occurs even if only the trunk in LOD0 has the tessellated material
The issue is easier to reproduce by zooming out from the trees
With the ‘zooming out’ way, the issue happens also without shadows, and also in Unlit mode
I couldn’t determine if removing all LODs except for LOD0 fixes the issue (there seems to be no way to remove LODs, and reimporting LOD1 using the engine cube crashed the engine at FFbxImporter::ApplyTransformSettingsToFbxNode() )
Is this enough info for you? definately looks like a problem with SpeedTree.
If you want I could package and send you this blank project where I made the problem occur as well.
I’ve been attempting to reproduce this error on my end with some speedtree assets, however I have not been successful thus far. If you have a sample project, I’ll be happy to take a look and see what may be occurring.
After looking at the project, I believe the error you are seeing is due to the sheer number of polys being tessellated at the same time. Currently, each tree is attempting to use both world displacement and tessellation to displace 32,000+ triangles per foliage instance, and then render that twice due to how foliage is calculated. Even on my work computer, which is running 32 gb of ram on a GTX 770 card , I saw significant slowdowns when using the foliage provided with only a few assets placed. I did not receive a video card driver crash, however. To be able to efficiently run this, you will either need to enhance your hardware or optimize the material to reduce its overall load on your GPU. Another option to try would be to reduce the poly count of the trees you are utilizing to attempt to reduce the load on your system.
I’m certain the error is not caused by what you’re describing. If you take a look at the initial post, I describe how the issue is non-existant if the trees are placed as StaticMeshActors.
Also the problem occurs even if the Tessellation Multiplier is set to 0.0 (in wireframe there is no visible tessellation at all)
Try those 2 things separately, you’ll just understand there’s something really fishy.
also even with the trees placed as foliage, if you just move the camera close enough to have the trees pretty much in your face closeup (and have much more tessellation), the issue is also gone.
And remember what I mentioned in an earlier post, if I remove the multiplication by WorldNormal in the WorldDisplacement in the shader, the issue is also gone, even with all the crazy tessellation going on.
With that in mind, it really looks like a specific issue and not an issue with my hardware. btw my GPU is a GTX 970
also,
The video card driver crash is not happening anymore because, A) I reduced the material complexity compared to my original project, and B) there’s only a few trees in that scene compared to my original project scene.
I just downloaded and tested your assets, and I believe the issue here is the intensity and complexity of your material using tessellation and displacement combined with the high poly model of your tree.
You mentioned the driver crash is no longer happens since you reduced the shader complexity, which means the issue you are experiencing it is a direct correlation with your materials tessellation.
I think what you have noticed is there is no difference between tessellation set at 0.0 and set to 1.0, which is expected since tessellation will not begin working until a multiplier at 1.0 and above. Setting your tessellation to 0.0 still means that your material is accounting for the VertexNormalWS and running those calculations.
As soon as you disable tessellation in this material, you will see the issue is completely gone. There is a difference in how foliage accounts for LOD distances, and when you paint a cluster a trees (versus hand placing them), they will use the foliage LOD settings. If you are using the LOD 0 or 1 (which are both considered high poly) and applying tessellation and displacement, it is expected they will cause a slow down.
I understand your view, but I’m sure there’s more to that. Consider the following, which I already explained before:
If you go to the material and just remove the part where it multiplies with VertexNormalWS for WorldDisplacement, the issue is gone. Yes that means you get the same amount of tessellated polygons on screen and they are still displaced (even with more displacement multiplier), which for me kinda rules out your explanation.
If you zoom in more, having the bark of the tree at closeup range (and therefore having more tessellated polygons on screen), the issue is gone. this also kinda rules out your explanation.
Reducing the material complexity turned the issue from a crash to a major slowdown, yes. But even if I remove all other nodes except the Tessellation Multiplier, a Texture multiplied by VertexNormalWS and a multiplier for that, it still gives a major slowdown.
This only happens with SpeedTree assets, but not with other assets, with the same material running the same complexity.
And I still don’t understand why one tree placed as staticmeshactor gives me 60 FPS and one tree placed as foliage gives me 8 FPS.
Next up I will try the same thing again, on a mesh with a similar complexity/polycount, but imported as a regular mesh (not speedtree).
Sorry but it’s just very fishy. I cannot believe that it’s the intended behavior that a high end feature works perfectly fine under one situation (placing 10 trees by hand) vs. another situation that is meant to give more performance (10 trees as foliage).
so I exported the mesh, cleaned it from degenerate data in every different way I know on my 3d package, imported it into unreal again, and the issue is gone.
of course this means I have no LODs because the export from unreal was only LOD0.
here’s the result, with displacement values 10 times bigger than before, and with tessellation multiplier set to 3.0 (which means its pretty much a solid thing in wireframe view)
sorry but can you clarify why you’ve accepted the answer? your answer still doesn’t make sense and it surely is not the right explanation to the problem.
apparently the SpeedTree mesh has some really obscure corruption in them, yes. and I guess I should check this with the SpeedTree people. but at the moment it’s unknown if SpeedTree is causing the issue or the UE4 importer of SpeedTree.
You said you resolved it by simplifying your material and removing degenerate tangents. This is not a bug in the engine as it deals with SpeedTree exporting correctly, and how you have modeled out the tree.
If you can reproduce this by making a simple SpeedTree mesh and a simple material with tessellation, then we can investigate further but even then it would be a problem with how SpeedTree handles exporting.
You not having LODs is also not an issue with Unreal as that is something you make in an external modeling program and establish the distances within Unreal.
As I mentioned, this is not a bug on our end as it was fixed by exporting your mesh, cleaning its properties in an external program, and re-importing, which worked as expected.
hi, I checked with the guys at speedtree and they can’t help with this.
here’s the thread I made on their forums: link
btw when I mentioned I resolved by removing what could’ve been garbage data, it’s important to realize that I also removed all UV data except for that of UV0, and that I removed all LODs (which is what’s causing the problem)
after further tests I found the strangest behavior (this - as I posted on their forum). I still get major slowdowns even if none of the tessellated materials are being rendered! can you really say it’s not a problem with unreal?
I made a breakthrough regarding this bug, and I have enough information and repro steps to determine that This is a bug on Unreal (and not at all SpeedTree related)
I managed to reproduce it on a simple sphere. Dead easy and clear.
The problem comes with LODs. So whenever you mix Tessellation + Foliage + LODs the problem arises.
And the problem becomes evident when the LOD to which the Tessellated material is applied is NOT being rendered (and another LOD is being rendered instead)
So, new Repro Steps:
Make a somewhat complex material with tessellation, making sure it includes a multiply with VertexNormalWS node in the displacement -OR- Open the project that I supplied before
Import a mesh with a semi-high polycount (I used a sphere with 10k polys), making sure that it comes with a low-res LOD (my LOD has 224 polys)
Apply the tessellated material to LOD0
place a few of those meshes as foliage
move the camera close to them, and move back
notice the horrible slowdown
Here’s a gif showing the problem. Notice Unreal’s onscreen FPS
Now can the issue be reopened again or do I need to make a new post?
Just wanted to chime in.
I had the same problem when I tried a while back. I tried tessellating tree trunks but the performance went to hell immediately despite having only a few instances and using LODS as well as decreasing tessellation with distance. The actual tessellation quality seems to hardly affect performance at all, there is some big overhead causing the major part of the drop.
The same goes for tessellating landscape. As soon as I turn it on in the material I loose a lot of performance without using any multiplier.
So I just attempted what you are reporting and could not reproduce the performance drop, but I did find a couple bugs that deal with Tessellation and Foliage as well as Tessellation and Landscape performance issues. In short, this is already a known and reported issue, and the examples you have shown are providing some good evidence of the issue. The issues (UE-21449) (UE-14253) also combined with the fact that tessellation actually did not work for a short time in 4.11 were probably all working together to make your experience more extreme.
The two bugs mentioned are still being worked on, and tessellation has been fixed for the official 4.11 release. We just pushed the 4.11.2 release as well, and I am curious to see if it occurs in this release as well. I can add this version to the bug reports if that is the case.
With that said, in case we need to download and test this issue again, could you provide me with a private message on the Forums with your example project? The original link you sent has expired, so we need a new uploaded version. If you have further questions, please let me know.
