No announcement yet.

Broken meshes after importing to Unity

  • Filter
  • Time
  • Show
Clear All
new posts

  • Broken meshes after importing to Unity


    First time SpeedTree for Unity user here. I encountered completely broken meshes and missing leafs on all the trees I've made, after they're imported to Unity. I couldn't find any notes about this on the documentation and it's clearly a bug.

    I've tried all the possible combinations from both export and import settings without any success. Is this a known bug, and does anyone happen to know a way to fix this and go around it?

    Here is how the tree looks in the editor when exporting ...
    Click image for larger version  Name:	Pine_speedtree.png Views:	0 Size:	372.9 KB ID:	8401

    ... and here it is after importing to Unity.
    Click image for larger version  Name:	Pine_unity.png Views:	0 Size:	767.5 KB ID:	8400

  • #2
    After going through the forum posts; I found out that this is indeed a well known issue.

    Unity mesh import pipeline uses 16 bit index buffers by default. Unitys SpeedTree importer hits that limit and causes the broken meshes. The importer needs to be either updated to use 32 bit index buffers, or split the mesh into sets of 65535 vertices. Since the SpeedTree exporter uses it's own special format; There is no way for us to go around this issue.

    Apparently this limitation has been known since the SpeedTree for Unity came out. Why there is no notion about this on documentation, and why doesn't the exporter take this into account? There is no way this can be considered to be production ready.

    We have used quite a lot of resources on creating the trees, and there is no possibility to change game engines at this moment of our production. So what options would we have?

    Following features would be needed:
    • Exporting FBX models from SpeedTree
    • Generating LOD's. This can also done after exporting the FBX models if there is no such feature.
    • Exporting wind animation data. As long we get the per vertex data we can build our own meshes and shaders to use those.
    Is there a different SpeedTree product we could use instead to cover our needs?



    • #3

      You figured it out before I posted an answer. Sorry you ran into this bug.

      The limit is 16bit indices / 65k vertices per draw call. If you break your tree up a bit, you can have more than 65k. And it really only affects hero models, as most real-time trees should be below 65k for performance. Your tree seems to be around 500k, which is very, very large for real-time environments.

      However, the fix for this is already in the pipeline for Unity releases, though I am unsure when it will be available. It also did not affect v7, just v8.

      If you do wish to export FBX from the Modeler for games purposes, you could look into SpeedTree Indie.


      • #4
        Hi Greg,

        Thanks for quick reply. Some of the trees we can go down quite a lot in vertex count, but for some we can't do that without sacrificing the visual quality target we have. For most game productions going below 65k might be the case. Our rendering pipeline and target devices are fine on using much higher density meshes.

        The limit is 16bit indices / 65k vertices per draw call.
        So there is a way to break down the trees we have to generate separate meshes?

        I will look into the SpeedTree Indie if it would suit our usecase better. Thanks!


        • #5
          Don't put everything into the atlas. For instance, set the atlas mode to non-wrapping. That will keep branches out as a separate draw call.

          But it actually looks like the bulk of your polys are spent in branches. You should be able to drop the segments, especially near the top, without much visual difference. Try using the profile curves and optimization. Also consider replacing the final twigs with a frond with an image on it. This will save massive amounts of polys.

          Hope this helps


          • #6
            Sounds like there is a lot of tricks for me to learn here for optimizing the data.

            I'll get into it and also try out the Indie version if that fits our pipeline better. While we might get the vertex counts down, we can't take the risk of the models breaking silently.