TeamLiquid Map Contest 5 - Page 8

On January 27 2015 18:48 Meavis wrote:

I never said they were rules either, while there is a lot of value in your post, I am a bit confused as to why you ignore the advice you give to others, on a giant map in 4v4, where FPS issues are most critical.

On January 27 2015 12:05 Uvantak wrote:



btw any doodad that inherits terrain colors/textures can be problematic if used too much just like any other doodad, but how about increasing the size of them? How about if instead of adding 6 Xel torn plates i add 2x300% ? I most of the time tend to go for the later, but it would be nice to know anyways.

This is a really good hypothesis, and actually does sometimes work. In the general case, smaller objects mean you have to draw more of them which can be bad, but larger objects can also be bad because they are less likely to be optimized away as "off screen". So there is optimization that can be done through size, but it is very hard to dial in. Unfortunately, increasing the size of Torn Plates or Ice Cliffs in particular will often make things worse. There is a "sweet spot" to their size.

We cache blended terrain textures for "terrain chunks". These are the red lined grid cells seen in the terrain editor. This is an optimization on most hardware, because you only have to do the terrain blending once, and can reuse it between frames. However, on some hardware/settings combinations, there is not enough memory available to cache all the terrain you can see at once. This is especially true in some of the "12-high cliff" tilesets, like Umoja, where deep cliffs north of the current view can cause more terrain chunks to be seen. I believe the "slow" cliff meshes are "Cliff Made13" and "Cliff Natural3" in particular.

When a doodad with terrain materials goes to draw itself, it first checks to see if it can use a cached terrain chunk. It can do this if it resides entirely within the borders of a single terrain chunk, and that terrain chunk has a valid cache. If it cannot use an existing chunk, either because the chunk didn't fit in memory, or because the model requires information from multiple terrain chunks, then it will attempt to render its own cached terrain chunk. This can lead to a "death spiral" for performance. The terrain doodad will request its new cache, possibly ejecting another cache, and now both will do their own terrain blending that frame.

This leaves an odd situation. If there are too many terrain material doodads crossing chunk boundaries, then it's super slow. If there are lots of small ones, then there might be more crossing overall. If they're too big, then each one is guaranteed to cross a boundary, and that would be quite bad. Also, it's really not reasonable for gameplay or artistry to ask people to dodge red lines constantly when placing doodads.

Therefore, the best advisory really is to be sparing with your usage of doodads with terrain materials. Terrain material doodads often help make a map look quite nice, they are in the game to be used, and the system is there to support it. However, the system works quite a lot better under its anticipated loads (i.e. 8-high cliffs, only a few terrain material doodads for accent).

Terrain Objects draw like the ground and do not suffer from this performance issue. Regular doodads also do not suffer. This issue is unique to Doodads that use Terrain Materials

On January 23 2015 19:05 Plexa wrote:
I present to you "MOTM + a few!"
http://imgur.com/a/JaDpG

Maps since MotM in June plus a few I grabbed from the top of the map section. These maps are generally very high quality and hopefully most of them will be submitted this season!

On January 28 2015 10:12 Psione wrote:

This caught the eye of one of our Senior Technical Artists who helps address map performance. Being particularly passionate about the work of community map makers, he wanted to offer some details on this. I know you guys really enjoy some of the finer points of this process, so I've offered the unedited and more technical answer that he provided.


Hopefully this info helps provide further insight into the complexities of map performance. If this confuses any map makers, it is likely not a scenario that you'll run into and shouldn't be too concerning. We're just offering this as extra info for those interested.

On January 29 2015 08:29 Uvantak wrote:


Ok.

+ Show Spoiler +

Can't post layout coz nothing final yet.

---

Almost forgot, thanks psione for posting the full answer, i love reading the more technical side of things!

On January 30 2015 02:01 Uvantak wrote:

I usually make maps in "litters", specially for things such as the TLMC's where i make several different or sightly different layouts/maps and test them in tandem so any possible idea gets even a little testing or know how it would change the flow of the map. Lately (december/jan) i have been toying around quite a bit with what ended up becoming Neo Gobi, the layout of the Protoss map is one of those maps that shares lots of similarities with Neo Gobi, but most likely than not it will be scrapped since i have already published a map that uses the layout, it would be redundant to publish two similar maps.