No announcement yet.

Speedtree 7.07. Oh geebs the crashes!

  • Filter
  • Time
  • Show
Clear All
new posts

  • Speedtree 7.07. Oh geebs the crashes!

    So I picked it up roughly around the time it went live. Hurrah! I said to myself, thinking my days of doing everything manually twig by twig were over and the magical new dawn of procedurals had begun.

    Oh how wrong I was.

    Anyway, I haven't had long to use the program, so there's still a lot of PEBCAK. Buuuut. Another guy picked up on this. Speedtree crashes every other moment. The only way I have to not guarantee a crash is to build under 10k tris. Everything above that seems to cause a fatal error and complete program death at completely random intervals.

    Though it will be guaranteed if I try saving. Which means I will be switching autosave off for the meantime because I prefer to work in the 20k to 30k range so I can get more complexity in my trees. Which is really frustrating because only about 1 in every 20 attempts will actually save. And once I get a saved file, generating new versions will cause crashes.

    Also. The program just seems to crash randomly. For no reason that I can see. You could be rotating the model, or just switch to another window and BAM! Gone. And saving regularly does work because.... well... it crashes.

    Now. I realise that some programs just lock up on their saves and then get operational again later once the save thingy is done. In which case, you guys should just freeze the program when the save happens with a message saying, 'We're saving your tree. Go grab a coffee and watch a movie.' So I tested that. It was just a permacrash, rather than a temporary crash.

    Also. Randomly generating trees to fast seems to crash the program. Obviously. So why not put in a check to see if the last tree has finished generating yet and the RAM or stuff has been flushed properly, before it generates the next tree, and maybe even a message telling the user to slow down a bit.

    On another note. A feature request. Can we get a full collision mesh generated, rather than those spheres. I'm currently in the process of making a game that involves trees, and more correctly, people in trees, smashing trees, and generally doing mean things to other people on top of tree branches.

    Manually generating collision meshes, while not difficult, is a time consuming export/import process that's prone to errors as formats swap around. So if you guys could implement some form of complex tree collision, that would be really, really fantastic. Co-opting the mesh generator might save a bit of trouble. I understand it's complex collision, but I'd rather that than sphere's a tubes that seem to generate under a random self assigned algorithm that makes no sense.

    Also. Is it possible to see an option for the cap material to be moved to another material slot? I'm trying to tweak the leaf material in unreal, and would prefer not to have to mask everything every time I want to modify the leaves. It sort of adds to the time. I understand if that's a bit too complex a task, and in which case, is it possible to export a mask of some kind with the material so we can selectively control which part of the material we're editing?

    Otherwise. Great program. I really love it. Despite all the crashes I've managed to make a whole bunch of trees and they work beautifully. The auto generation of material's is a wonderful time saver and is extremely helpful given the relative lack of useful documentation that UE4 has.

    Keep up the good work!

  • #2

    Sorry to hear you're having so much trouble. This is the first we've heard of anything like this. We routinely do everything you mentioned without any issues so I'm hoping there's something about your setup that will point us to the problem. Can you tell me what platform you're running on and what graphics card you have? Are you seeing these issues when using our sample models? If not, would it be possible for you to send us a model you're using that crashes? We'd really like to figure out what's going on here and put out a fix. The fact that it crashes when just rotating the model leads me to believe it's a graphics card issue. Are your drivers up to date?

    Regarding the caps, give this a shot: go to the cap material and in the 'Compiler' group change the 'Usage' property to 'Force copy'. There will be an extra draw call in the resulting model but the caps will be rendered separately and won't be in the atlas.

    Regarding the collision mesh, how would you like to see that work? An option that just uses the geometry (maybe just the branches) as the collision mesh during import to UE4? Would you want a lower poly approximation or would the actual mesh be okay?


    • #3
      Hey sorry it took so long to answer. It's a busy time at the moment.

      To answer your questions. I'm using an Nvidia 580 with the 980X i7 hexacore. OS is Windows 7 ultimate. All drivers are the latest, I regularly clean up my system and keep it running smoothly.

      One of the things I'm noticing with crashing is that it seems mostly related to saving, whether autosave or otherwise. And the crashes happen after about 12k tri's. Obviously I'm still figuring out the best optimisation process.

      For some reason generating spruce branches off of standard or pine trunks seems to generate more crashes. I just did a quick test - Standard trunk -> spruce branches -> cut frequency down -> broadleaf structure (I intended it to break). The tree generates fine, 1 mill tris. Heh. I cut it down to about a hundred k, then it crashes when I accidentally pull the twigs to zero. Oopsies.

      Anyway, I uhhh tend to attract bugs. You get used to it when pretty much every program you use will screw itself in wonderfully versatile ways. It's one of the reasons I vowed off Autodesk products. They hate me like the plague. Everybody else is fine and for me they just sort of progressively break down into a perfect storm of doomed models.

      I've attached a file I know will guarantee a crash if you just hit randomise and save on a model. Seriously, just hit randomise and save incremental and she's down for the count. If it does fall through, and actually save, just keep going.

      On a side note. I noticed that some incrementals don't generate a .srt file. Is that intended? Coz I've done it a few times, and only the first model and the third incremental of that saved srt's. Do you generate the srt files on program exit? On save? On save as?

      I'm surprised you would consider more advanced collision. That's amazing!

      Basically, my current process is to grab the mesh and run a simplification modifier that kills the polys while retaining the overall shape. I can scale it and then export as a ucx, which seems to be UE4's shorthand for collision meshes. The process is a little arbitrary and confusing, but I'm sure it made sense at the time.

      Ideally, a scaling system like what you do with your LOD's is preferable, but any system that allows the origin mesh to be used will be very useful. For our project, we only need the trunk and branches to be collideable, anything further isn't needed. Given what people always do with games, I'm sure there's someone else who'd need the twigs and leaves to collide as well.

      I'd suggest culling polys to the absolute minimum required to keep the shape and giving the user the option to scale up or down if necessary. So for instance the tree trunk might only have five radial polys and the branches after level 1 might just be flat planes.

      File uploaded to mediafire because big textures are big.

      Feel free to ask any questions, I tend to break all the programs I touch, and it's often quite difficult to isolate why, but I'll see if I can test to figure out what's happening.