Map Optimisation

[SoloJoke]

Hey, so I'm starting to notice that the larger you make maps, and the more walls and lights you add to it, the slower things become. There's lag between when you can move or add things around like tokens or walls, and there are increased load times for the maps themselves. Now obviously some level of this is expected, but I feel like it doesn't take much at all to start slowing things down. Maps that are around 4000 by 4000 pixels, which is about 100 squares on either side, are starting to lag, and it just gets worse from there.

Is there something I can do on my end to optimise this further? Or is this just something I need to wait for the devs to optimise on the back end?

[Zarestia]

From what I've read some optimizations are currently in work, if they address the things you pointed out, I don't know.

Some things to consider:
- Map size in MB is mostly relevant for sharing speed (upload from GM's machine)
- GPU load comes mainly from the display size (resolution) on your screen. The same map has a higher load maximized on a 4k display than on a Full-HD display
- The more LoS points (careful with circles), the more Lighting points and the more FX layers, the more lag. When a bit of lag starts to happen, I don't know. I've played on a 5500*7500 map with all things enabled on a 2k monitor without problems

You could upload your campaign as zip or upload an exported module out of the map so others can take a look at that specific example.

[LordEntrails]

The biggest thing I see a problem with is number of LOS points. Many people feel that the LOS needs to follow the walls exactly and this become especially troublesome with caves and irregular shapes.. IMO, LOS does not, and should not (because of performance), follow the walls exactly. For instance, tokens can only be placed at 9 places in a square, and there is only so much need for the LOS to have a resolution against what one token can see. Therefore I strive to make sure I never do more than 2 LOS points per square. And usually much less than that, even on very jagged cave systems.

IMO, many of the LOS in the official maps are way too detailed. I understand why they are the way they are, but it's one of the things I find troublesome.

The next thing that I find impacts performance is number of map FX. It's easy to go overboard layering and masking these.

Plus of course number of light sources.

[SoloJoke]

Hey, thankls for the reply, I'm glad the optimisation is in the works, I've had great experiences with FGU so far.

My maps are super small, I use simple maps, so they are like 1 or 2 MBs max, and they are usually much less than that.
I don't use a 4k display, I'm just on a basic 1080 display.
I do have a lot of walls, but not more than any of the standard D&D maps that would come with like Into the Abyss or Lost Mine of Phandelver, or any of those adventures.

I could upload an exported module of that map to see if other people have that problem too, if not then maybe it's a problem on my end?

[Moon Wizard]

I will second what LordEntrails says. While we continue to attempt to fine-tune vision/lighting/LoS/FoW behaviors, at the end of the day, there is a limit to how much data can be processed quickly while tokens are moving. Remember, to the computer and the FG code, the LoS points/segments are just a bunch of points/lines that have to be checked. There's no inherent way to prune out points/lines as not visible in LoS, until you actually do all the calculations. We're going to continue to work on fixing and adding features, as well as looking at ways to improve optimization.

Regards,
JPG

[SoloJoke]

Alright, here is the module that inculdes the map I was using, and the actual map image itself. The Savage Halls is the map that will be the worst, since it is the largest, and it was almost unplayable. If at least one player was moving their token, not only would it be incredibly laggy for them, but it would be so laggy for me that I couldn't do anything at all until he stopped. It would be cool to know if anyone else has the same issues as me with it, or if there is some way to optomise it further, etc.

49202

[Moon Wizard]

FGU v4.1.8 was pushed last night with some specific fixes for performance on maps, including planned token movement. If anybody is still having issues after updating, please make a new thread with a copy of your campaign folder and a note about which map is affected.

Regards,
JPG

[pindercarl]

Alright, here is the module that inculdes the map I was using, and the actual map image itself. The Savage Halls is the map that will be the worst, since it is the largest, and it was almost unplayable. If at least one player was moving their token, not only would it be incredibly laggy for them, but it would be so laggy for me that I couldn't do anything at all until he stopped. It would be cool to know if anyone else has the same issues as me with it, or if there is some way to optomise it further, etc.

49202

@SoloJoke I was testing your provided module with the recent improvements. We have noticed that the ellipse tool was producing too many points for the user data we've been seeing and recently reduced the number of points created. I rebuilt the circular walls on your Savage Halls map and the performance increased 54%. I imagine you would find similar, or better results, on the Godemagne's Wetlands map.

[jharp]

As a further improvement UI wise can we please make the ct_effect.label control delay key update. Presently if you have a torch effect set for a map as provided it is very slow to update the effect text.