Change the heightmap without repathing

[zwzsg]

I've been told heightmap changes are so slow because of the repathing.

I had those awesome ideas of fighting over an ever-changing ground, but sadly, this it not possible because even when:
- using the SetHeightMapFunc thing to speed thing
- changing only every 8 distance unit and every 3s
- only on the area of 4x4 map
The strain on the CPU is felt heavily.


So, if re-pathing is the bottleneck, I'd like an option to disable repathing when changing heightmap.

I have understood and agree that units might do stupid agree, but I don't care about that right now. First I want to play on smooth wave. Only at a later stage I'll come back to complain about how my terrain changes were not taken into account by units.

Quantum told me posting this picture would be a motivator:

[Pxtl]

omgwtfbbq.

[Argh]

Yet another valid reason to tell the pathfinder to not choose the "efficient" route for a given unitID via Lua. +1

[Auswaschbar]

Do not believe rumors. Do some profiling instead (or let someone do it for you).

[Argh]

If the pathfinder's not the problem, then what is it then? There surely is a big hit when maps start getting deformed. Is it just the engine having to re-tessellate the heightfield?

If you're saying it's not very, very costly to do large-scale heightmap stuff, I don't buy that, specially not for something like zwzsg wants to do.

That's a lot of very heavy math there. IDK how he's supposed to make that work quickly enough for players even if the pathfinder isn't an issue at all. But I digress.

[zwzsg]

Do some profiling instead (or let someone do it for you).

I'm indeed looking for a profiler. Or at the minimum someone who can port me the existing profiling tool. Do you volunteer?

[Peet]

Is it just the engine having to re-tessellate the heightfield?

Your latest buzzword does not work for every situation...perhaps you should find a new one.

[Kloot]

I've been told heightmap changes are so slow because of the repathing.

There is much more that needs to be updated when the heightmap changes (the heightmap itself, the height _texture_, the normal-map, the slope-map, the terrain LOS states, unit positions, feature positions, ...), so you've not been told the full story.

[Auswaschbar]

Do some profiling instead (or let someone do it for you).

I'm indeed looking for a profiler. Or at the minimum someone who can port me the existing profiling tool. Do you volunteer?

• compile spring with profiling information
• run your test case
• let gprof generate some tables
• (mak nice graphs eventually)
• profit

Or give me your wobbling widget.

[zwzsg]

Actually, it's the mod as I whole that I'd like to profile. May I have a copy of a Win32 Spring.exe with profiling on and gprof?

[Argh]

Your latest buzzword does not work for every situation...perhaps you should find a new one.

But the warranty period hasn't expired yet?

Moreover, there is no short way to describe how a not-quite-done ROAM implementation (or whatever's being used for mesh decimation in SMF) works.

[zwzsg]

ROAM implementation

He found his new one, Peet!

give me your wobbling widget.

[Auswaschbar]

Code: Select all

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
 34.84      8.38     8.38 85894454     0.00     0.00  streflop_libm::__ieee754_sqrtf(float)
 12.35     11.35     2.97  3896129     0.00     0.00  CBasicMapDamage::RecalcArea(int, int, int, int)
  7.86     13.24     1.89 34857289     0.00     0.00  CSmfReadMap::GetLightValue(int, int)
  6.82     14.88     1.64   130125     0.00     0.00  luaV_execute(lua_State*, int)
  2.29     15.43     0.55 40723693     0.00     0.00  luaV_gettable(lua_State*, lua_TValue const*, lua_TValue*, lua_TValue*)

See? Nothing even related to pathing in the top 5 CPU time consumer.

[Argh]

Code: Select all

12.35     11.35     2.97  3896129     0.00     0.00  CBasicMapDamage::RecalcArea(int, int, int, int)

Isn't MapDamage triggered any time a heightmap square changes at all?

And doesn't that feed back into the pathfinder every SlowUpdate?

Not that that would save this idea, which has to involve a ridiculous number of very complex calcs per frame.

[smoth]

you are too fucking awesome zwzsg

[Jazcash]

Quantum told me posting this picture would be a motivator:

Quantum. At 0.8MB/s. I hate you.

[zwzsg]

Not that that would save this idea, which has to involve a ridiculous number of very complex calcs per frame.

How so? Which "very complex calcs" are you talking about? The lua performing the 66049 sinuses does not cause any slow down, I tested. It's only when I use the Spring.LevelHeightMap instruction that it kills the CPU. What in the changing the heightmap cause slow down, I don't know, deciphering Auswaschbar's profiling result is too hard for me.

[Auswaschbar]

simplified for zwzsg:
CPU hooks:

1. map damage recalculation (dunno what it does)
2. Lightmap calculation (for shadows and stuff I suppose)
3. lua

[BaNa]

Damn if this could be made to work properly we would be in for so much FUCKWIN it is not even funny.

[koshi]

http://en.wikipedia.org/wiki/Lookup_tab ... ting_sines btw