Thanks martin. An engine upgrade is non-trivial for us since we’ve made a number of source changes in other unrelated systems. It can be done but we’re close to a playtesting milestone and are a bit weary of the number of regressions we might face due to the many changes found in every engine upgrade. With that said we’ll certainly consider it. As for the fastgeo plugin, we kind of already have something like that, at cook time we pack static mesh components into isms if they are the same. This dramatically reduces component creation when streaming (though that doesn’t solve our physics problems, which has largely been the topic of this discussion).
I ran a simple test based on your suggestion like so:
[Image Removed]Unfortunately I’m still seeing lots of hitches that look like this:
[Image Removed] Are part of these tasks not currently timesliced at all? Or is there another case where flushes can occur that I’m not aware of?
Also we’re seeing some strange behaviour where sometimes world partition goes way over budget. We don’t have “block on slow streaming” checked and yet if we travel quickly through the world, it looks like world partition starts adding levels at a much greater rate regardless of being well over time:
[Image Removed]