[Bug]:Huge delay when undo-ing translation of big brush

Development World Creation
, , , ,
1

I’m experiencing pretty long delays when I undo an action where I have moved a big brush over a bigger distance.
This is happening in more or less empty level. I have few big brushes, scale is about 1000m for a box and radius about 500m for a cylinder. If I move such object, let’s say 500 meters and then undo action, I get delay of 15-30 seconds until undo happens. This seems to be getting worse if I move a few more objects at same time and then undo action.

I know 1000m brushes are not something that should be generally used, but this is just very early whiteboxing phase.

I tried to reproduce problem in new map, but it wasn’t that easy. As I added a few more big objects, I started to notice small lags on undo, but not that huge as in mentioned map. So I guess it is something particular in that scene and therefor I have attached it.

2

Hey ,

I haven’t been able to reproduce issue as described. Can you give us a little more detail about level before you started using these large brushes? How many brushes do you have of this size in level when this occurs? Have you been able to reproduce it in your new map over time?

Could you also tell us your machine specs and OS version? Thanks!

3

level was made from scratch, with Default preset. And not much has been done before started adding those big brushes. I first noticed problem right after there were maybe 5-6 brushes in level.

I tried to reproduce problem in a new level, but so far I have seen only minor slow down which is ok.

I was hoping it would be possible to figure out problem from attached map (seems like attachment didn’t make it :slight_smile: ).

Anyway, specs:

  • Win 8.1
  • Core i7 4.2GHz, 16GB RAM
  • GTX 760 with 2GB of RAM

And here is map again -

I will try to reproduce bug, but it could take some time. I will update this thread when I get some results.

4

Hey ,

I was able to reproduce issue on your map, though not in my own. I have entered a report and included your map for reference. Thanks for your report! If you are able to reproduce it on a new map and can include some reproduction steps, please let us know.

Thanks again!

5

I will surely let you know if I have some repro steps. Thanks.

6

Ok, I got repro steps:

  • create a new map
  • add a cylinder bsp
  • set it’s radius to 50000
  • create around 10 copies of cylinder via ctrl+c/ctrl-v
  • at this point moving one of brushes away and undoing action should be still ok
  • now move every brush away from other so that they all are visible and don’t overlap, I have placed them into 3 rows and 3 columns
  • now if you move one away and hit undo, you should get slow-down
  • number of sides of cylinder seems to affect undo time, try selecting all brushes and set side to 3, undo should be now much faster

These might be a bit extreme cases, but it seems to affect performance even if you do things a bit smaller (but still rather large) and use more brushes (10 is really not that much). Also other things could affect this, like if terrain is presented, but I’m not sure about that.

7

I have exact same issue. I’m making a relatively large map and even in early BSP stages, I can’t undo any BSP placement or changes without a 10 minute delay that typically results in engine crashing. Any idea when we’ll get a solution?

8

Hey Liforce,

BSP system is performance-heavy, and this will likely not change until Geometry 2.0. This does not currently have a timeline, but you can vote for interest in it here:

In meantime, if you are working extensively with BSP brushes, it will be a much smoother experience if you prevent BSPs from updating automatically. You can read more about that in this post:

Hope that helps!

9

Any progress on fixing BSP performance?

10

I simply refrain from using undo key. If I move a piece of BSP, I always remember change so I can undo it manually if need be. If change is too complex, I am forced to delete BSP and remake it. It sounds time consuming, but for level of complexity on some of my pieces, it is much faster to start from scratch than to wait for editor to undo piece.

I still use level streaming and converting BSP to static meshes to reduce any effect of slowdown, but it still persists.

11

Hey Slonopotamus,

Not yet. BSP performance will likely not improve until new system is implemented, and there is no timeline for that yet.

12

So there is a real technical reason in current BSP system why undo (ctrl+z) has to be orders of magnitude slower than manual moving of BSP to previous position?