Hello! I’ve been experiencing crashes involving SpeedTree since 4.3. I am using the 4.4 release.
InstancedFoliage.cpp
/* Get the number of placed instances */
int32 FFoliageMeshInfo::GetInstanceCount() const
{
int32 Count = 0;
for (int32 Idx = 0; Idx < Instances.Num(); Idx++)
{
if (Instances[Idx].ClusterIndex != -1) //THIS LINE IS WHAT VS BREAKS ON
{
Count++;
}
}
return Count;
}
Here is the data from the Autos tab:
Count 0 int
Idx 0 int
+ Instances Num=1097164641 TArray<FFoliageInstance,FDefaultAllocator>
+ this 0x0000004a4f25f1a0 {InstanceClusters=Num=1226848884 Instances=Num=1097164641 InstanceHash={Ptr=0x6174736e492e305f {...} } ...} FFoliageMeshInfo *
And the members of every FFoliageInstance equals ???. Same with InstanceClusters. I will report back here when I experience another crash. Thanks!
I’ve experienced a lot of crashes with Speedtree as well.
Also for some reason when I try to re import Speedtrees it looks like it’s working but nothing changes, I’ve reported this on the Speedtree forum but no answer yet. I’m still using 4.3, haven’t tried 4.4 yet.
Reimporting of SpeedTrees should work. It’ll pop the importer dialog up again so you can change things about the mesh. It’ll only reimport the mesh itself, though. If it finds textures and materials already there, it will just use them. So if a texture changed, you’ll want to reimport that, too.
But to get back on topic, that crash doesn’t look like it’s anything specific to SpeedTrees. However, SpeedTree meshes may be doing something not usually done in foliage (like multiple LODs perhaps).
Though I can’t speak to the programming aspect, perhaps Epic and SpeedTree should think about adding a feature where it deposits the project-state in a crash backup file; easy for retrieval upon re-opening the Modeler interface…
If then it happens again right after it is opened, the program could also be designed to automatically forward the project-state to SpeedTree for UE4 Support for analysis.
