Terraindeformation and Lag

[Zeatherann]

When I create dozens of terraindeformations with crater deformations the game decides to cap out the core that it runs on. Are they that bad on performance?

 

[Veritas 117]

They must be. That is the reason I don't use shockwave and warstomp (or was is thunderclap) as dummy spells. They are hardcoded to cause terrain deformations and lag like crazy.

 

[Zeatherann]

I never noticed it before. On my testing map I created a ton of deformations and it used 25% of my total cpu (or 100% of a single core). However, in my map Infection I use deformations to create the entire terrain environment (yes I know they leak). I had other stuff going on in that map so I wasn't surprised to see it cap a core out. I believe that Blizzard made a mistake for giving deformations too much clock time, but gives it to them last in the render loop because Infection doesn't lag. I could be all wrong here. Anyways, was hoping to see if anyone had helpful guru insight into this.

 

[Cokemonkey11]

terrain deformations cause permanent leaks. Dozens probably does nothing, but if you use 10,000 to create dynamic terrain the game will lag from memory usage. The CPU core should NOT be capped, though.

 

[Zeatherann]

High ram useage doesn't cause lag, latency, or a higher cpu useage. Poor programming does.

 

[WaterKnight]

Depends on the amount of objects that may get tilted due to the ground deformation.

 

[Cokemonkey11]

Depends on the amount of objects that may get tilted due to the ground deformation.

Does that mean that setting units maximum roll angle to 0.0 will fix the lag? Or is the issue due to roll calculation?

 

[Dr Super Good]

Terrain deformations are non-deterministic between the Windows and Mac client builds and will cause them to split (Out of Sync) if any attempt is made to access the terrain Z.

They are also non-deterministic with the same client build at different visual settings due to them generating different results. Although everyone should be running at high by this age it can still cause people who are not to split (Out of Sync).

For this reason you should never use them in your map. The exception is if your map is single player only in which case the non deterministic results are mostly a non-issue.

This is not limited to the deformation triggers although they are worst for causing problem. Shockwave and War Stomp also generate deformations which suffer the same problem and were the cause of the infamous split that plagued SWAT Aftermath for several years.

 

[Zeatherann]

Besides getting the terrain height at a point how can deformations desync players? Again, my map uses it exclusively to generate the entire terrain and no one has disconnected before.

 

[Dr Super Good]

Besides getting the terrain height at a point how can deformations desync players? Again, my map uses it exclusively to generate the entire terrain and no one has disconnected before.

Not entirely sure. All that I know is that the deformation results produced are not deterministic and so will produce different results depending on the system that runs them. An example may be that systems running WC3 on low visuals (settings turned down) may have them lacking detail or even be missing entirely. Maybe only if get location z is used will it introduce the non-deterministic results into the game such that an out of sync occurs but the fact is that deformation results are not deterministic and can be different from system to system.

 

[WaterKnight]

Wc3 does not use z for gameplay on default. So no, you won't get desyncs by just using terrain deformations. I do not know how it is system-dependent, maybe it only affects the transitions or the models of walkable destructables.

 

[Cokemonkey11]

Wc3 does not use z for gameplay on default. So no, you won't get desyncs by just using terrain deformations. I do not know how it is system-dependent, maybe it only affects the transitions or the models of walkable destructables.

I believe PanCameraToWithZ() breaks.

 

[Zeatherann]

Well. Since Infection has its own method of getting terrain height and uses that method to keep the camera above ground, I have to worry about regarding desyncs.

 

[Dr Super Good]

Wc3 does not use z for gameplay on default. So no, you won't get desyncs by just using terrain deformations. I do not know how it is system-dependent, maybe it only affects the transitions or the models of walkable destructables.

Visual settings change how they are computed. They should be fully deterministic between two clients running the same version of WC3 at the same visual settings. Most noticeably is when set to low they may be missing or produce very crude results.

There is a portability bug with the game client resulting in the results not being deterministic between Mac and Windows users. This applies even if both run at the same visual settings. This is likely due to a subtle difference in the results from the involved floating point operations as a result of different platform specifications.