Spring RTS Engine

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:

omgwtfbbq.

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

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

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.

Auswaschbar wrote: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?

Argh wrote: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.

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.

zwzsg wrote:

Auswaschbar wrote: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.

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?

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.

Argh wrote:ROAM implementation

He found his new one, Peet!

Auswaschbar wrote:give me your wobbling widget.

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

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.

you are too fucking awesome zwzsg

zwzsg wrote: Quantum told me posting this picture would be a motivator:

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

Argh wrote: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.

simplified for zwzsg:
CPU hooks:

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

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

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