Are current map size limitations expected to increase?

[Sterno]

I believe the current map size recommendation is 4k x 4k pixels. I'm running Arden Vul and even when I break a level's maps up into chunks, I'm still getting 8k x 8k or more in map size. My players are seeing performance issues with lightning and LOS, and the explanation I've heard is that it's likely due to the map size.

I'm curious if that 4k x 4k limit is meant as "this is a good thing to stay under until we make some lighting/LOS performance improvements, which we totally expect to make soon" or if it's more of a "This will probably be the limitation for a long time going forward" sort of thing.

If the latter, and we're expected to break big maps up into a bunch of chunks due to FG performance issues, then I think it would go a long way towards easing that pain if FG would build something right into the app like the rob2e's Portals extension, so that players can teleport from point A on one map to Point B on another. I mean, I'd love that being built-in either way, but particularly if we're being asked to limit map sizes, providing tools to deal with large maps that have to be broken up into chunks would be really nice.

[LordEntrails]

The current recommendation is, my understanding, based upon; FG calculation performance (LOS, lighting, etc), common network limitations (something FG doesn't/can't control), and hardware capabilities (something else FG can't control).

As the general population gets better bandwidth and more capable computers, I expect those impacts to the recommendations to be reduced. Calculation performance is something that is being worked on. But, setting a goal or a timeframe for such is ... probably more difficult than actually doing performance improvements themselves. From a programming point of view, working in a new platform on a new/unique application and having no previous experience doing performance tuning on that platform and application means their is little basis for estimating what can be done or how long it might take. (i.e. performance tuning FGC is good experience, but not a directly correlation to predict what can be done with FGU).

Also, what is short/long term to one person is not that same as what another person might expect.

In short, I expect the answer to be "wait and see", as incremental improvements will be likely for the foreseeable future (~2 years?) but if they stumble across or discover something that yields an evolutionary change then all the better.

[Zacchaeus]

I don’t think there’s any science to this and it’s just a recommendation for developers to keep the images to a sensible scale. The 4kx4k is just a doubling of the Classic recommendation. It’s not something that is set in stone. But realise that if you go for some colossal .png file with thousands of occluder points and tons of lights you’ll see a performance drop. Groups will vary in terms of computing power and internet connections and you’ll find your own limits as what is possible given your groups configurations.

Developers have to consider that the modules they are developing will not always be running on top end machines with lightning fast internet speeds.

[Sterno]

I don’t think there’s any science to this and it’s just a recommendation for developers to keep the images to a sensible scale. The 4kx4k is just a doubling of the Classic recommendation. It’s not something that is set in stone. But realise that if you go for some colossal .png file with thousands of occluder points and tons of lights you’ll see a performance drop. Groups will vary in terms of computing power and internet connections and you’ll find your own limits as what is possible given your groups configurations.

Developers have to consider that the modules they are developing will not always be running on top end machines with lightning fast internet speeds.

When people bring up performance issues with larger maps and lighting/LOS, the response is usually "use smaller maps. FG recommends 4k x 4k". What I'm trying to gauge is if that's a semi-permanent number that is deemed "good enough", and if you have performance problems beyond that, you're expected to make your map smaller, or if this is currently considered by the devs to just be a stopgap workaround until things can be improved. I want to know if I should start looking at creating something of my own similar to Portals to work around the problem, or if there's an expectation that in the next year or so, performance issues will be ironed out and maps should be able to be much larger. Yes, I understand 4k x 4k is kind of a guess, and # of occluders and all that matters. However, that 4k x 4k number is invariably the response you get when you mention performance problems for a big map.

And to be clear, I'm talking about maps for my own use, not for general consumption as a published module. I understand why a published module might be more strongly encouraged to use smaller maps.

I think I'm mainly looking for a dev response, not a guess from mods. We can all make a guess, right? And I'm curious if the map sizes are expected to need to remain smaller, if there will be any support added to link maps together.

[Trenloe]

I think I'm mainly looking for a dev response, not a guess from mods.
Then I suggest contacting SmiteWorks directly.

[Sterno]

Then I suggest contacting SmiteWorks directly.

You feel they won't see this, or that it isn't of general interest to more than just me?

[Trenloe]

You feel they won't see this, or that it isn't of general interest to more than just me?
Maybe they won't see it and I'm sure others will be interested - so maybe report back when you hear something. My concern is more wasting everyone's time all round - from your response in post #4, you're looking for a specific answer from SmiteWorks only and not interested in other non-SmiteWorks employee responses. A couple of active community members spent some of their free time replying to you, and you basically weren't interested in their responses (or, at least, that's how it came across). You posted in a public forum so should expect responses from people who don't work for SmiteWorks - in fact, the majority of responses will come from people who don't work for SmiteWorks and yes there is that chance that SmiteWorks devs may miss your post. If you want a response from SmiteWorks and aren't interested in community guesses then please directly engage SmiteWorks for your answer.

[Sterno]

I should have worded my response more politely and I apologize for that. My mistake was probably starting a new topic about this rather than bringing it up directly in one of the support threads about performance that MoonWizard has already been responding to. I didn't want to derail an existing thread.

Basically, I feel like a lot of us are left guessing about what the actual priority of performance issues are with bigger maps, and it's very hard to tell if "make your maps smaller" is meant as a temporary solution or is considered "good enough for most users, not high enough priority to spend time on any time soon". Because "make your maps smaller" is an answer we get a lot, and if that's basically a semi-permanent solution to the performance problems, then maybe as a community we can focus on ways to make that necessity less painful.

[LordEntrails]

I will add that as I tried to get at before, performance is not a binary. It's not a yes/no thing. It's all about gradients and expectations. And note, that some of the maps that people have recently reported having problems with were 40k x 40k pixels. That's not 10 times larger than a 4k x 4k image. So, to me, suggesting, "make your map smaller" is not a "hey you will need to make it smaller for a week or a month" But a rather, "Its going to be years or decades before that type of map is considered reasonable".

Let me also add, SmiteWorks almost never states what their priorities are or what they are working on is. But they have continued to state that they are continuing to work on performance and it is something they see as being a continual process. So, I would say if one were to come up with a comprehensive way to measure all aspects of performance in FGU, that a 2-5% increase per month might be a reasonable goal. That said, I don't think there is a comprehensive way to make such a measurement.

But, if you want something other than opinions from other community members, as Trenloe said, the best way is to ask SW directly and report back to us. I'm sure many of us would be interested.

[jharp]

I would love to know if FG implemented in Unreal would have the same issues. Boy would I like to port FG to Unreal.

Jason

[Zarestia]

I would love to know if FG implemented in Unreal would have the same issues. Boy would I like to port FG to Unreal.

Jason

A tool is only as good as the one using it. Great and bad products have been published with both engines, it's mostly personal preference and finding a suitable engine for the project (2D, 2D, film, AR, VR, visual novel, etc.)

----

Personally my biggest map was ~6k*6k with 6 PCs with one small hiccup of 1-2 sec.

When speaking about performance, keep in mind the many different layers:
- FGU Engine (we can't see)
- Ruleset (is never perfect)
- Possible Extensions (=risk)
- Possible Modules (a bazillion LoS points, a dozen FX layers, etc.)
- User Data (Internet speed, pc specs, etc.)

We (the community) can only look at the bottom four points. As the modules and user data are the things with the most variable settings (everyone uses the program differently) most troubleshooting and recommendations are made there.
If you are seeing performace issues, post them in the House of Healing Forum with as much information as possible. That way the devs can identify possible problems faster. Developing is no magic.

[jharp]

A tool is only as good as the one using it. Great and bad products have been published with both engines, it's mostly personal preference and finding a suitable engine for the project (2D, 2D, film, AR, VR, visual novel, etc.)

----

Personally my biggest map was ~6k*6k with 6 PCs with one small hiccup of 1-2 sec.

When speaking about performance, keep in mind the many different layers:
- FGU Engine (we can't see)
- Ruleset (is never perfect)
- Possible Extensions (=risk)
- Possible Modules (a bazillion LoS points, a dozen FX layers, etc.)
- User Data (Internet speed, pc specs, etc.)

We (the community) can only look at the bottom four points. As the modules and user data are the things with the most variable settings (everyone uses the program differently) most troubleshooting and recommendations are made there.
If you are seeing performace issues, post them in the House of Healing Forum with as much information as possible. That way the devs can identify possible problems faster. Developing is no magic.

I certainly agree with your sentiment that people that don't have a good grasp on a platform can product bad products. As I said I would love to port it to Unreal.

Jason

[Valyar]

As I said I would love to port it to Unreal.

Jason

And what this Unreal engine will bring?

[jharp]

And what this Unreal engine will bring?

Possibly nothing. Maybe something. But it is moot without SW agreeing.

Jason