Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blowing up a huge amount of TNT causes performance fail #3010

Open
Wuzzy2 opened this issue Jan 30, 2023 · 7 comments
Open

Blowing up a huge amount of TNT causes performance fail #3010

Wuzzy2 opened this issue Jan 30, 2023 · 7 comments

Comments

@Wuzzy2
Copy link
Contributor

Wuzzy2 commented Jan 30, 2023

If you blow up a HUGE amount of TNT (like, a 100×100×100 cube), the game quickly slows down to a crawl after the first explosion.

@appgurueu
Copy link
Contributor

I'd say this is roughly to be expected. TNT explosions simply are expensive. Even if you got them down to 1ms per explosion, blowing up a million (100³) TNT nodes at roughly the same time is expected to take a thousand seconds.

That said, there very likely is potential for optimization (even though such "HUGE" amounts will always slow the game down to a crawl). Might take a look using the LuaJIT profiler eventually.

Some options I see:

  • Optimize TNT. This won't suffice to fix this issue.
  • Add TNT explosion scheduling, delay explosions if a budget is exceeded. Will keep the game playable at the cost of the explosions being, well, delayed, which is inaccurate. Your million TNT nodes would be exploding for a while.
  • Do some batching of nearby TNT explosions (likely nontrivial). Might suffice to fix this issue without a "compromise".

What would you suggest?

@Wuzzy2
Copy link
Contributor Author

Wuzzy2 commented Jan 30, 2023

I have no suggestions yet, but there is one other thing to look at:

  • If there is a high number of particles, client comes down to a crawl (this is a separate issue, I think)

But yeah I believe this is hard to do right, especially due to possible exponential growth. :-( I also agree with low priority; I don't really care that much about the bug but I posted it anyway for documentation purposes.

@Desour
Copy link
Member

Desour commented Jan 30, 2023

If the blow takes longer (i.e. happens over many server-steps), the affected area could be hidden by a big fireball or mushroom cloud mesh. Or the view of nearby players could be obstructed by a hud element filling the entire screen.

@appgurueu
Copy link
Contributor

If there is a high number of particles, client comes down to a crawl (this is a separate issue, I think)

Yes, mostly an engine issue (although again "batching" as described by Desour could be seen as mod responsibility)

@tenplus1
Copy link
Contributor

Agree'd, massive tnt explosions can bring any system to a crawl which is why I limited particles and disabled some non-essential functions for it to work a little more smoothly for my own fork: https://notabug.org/tenplus1/tnt

@Destroyinator69420
Copy link

I could see a flag in the game that when a large enough amount of TNT is detonated, then the game will skip the visuals of the detonation and skip straight to the result. Mojang did this in minecraft pi edition as well as early versions of minecraft pocket edition too.

@SmallJoker
Copy link
Member

SmallJoker commented Jun 28, 2023

The TNT mod could make better use of ...

  1. VManip: by recursively collecting all TNT in range to then get one VManip object of the entire affected volume to then process each TNT position.
  2. Protection checks by using minetest.is_area_protected within radius (i.e. cube that encloses the sphere) to reduce the minetest.is_protected calls roughly by the factor 2³ = 8.

As soon the affected volume size is known, such performance optimizations could be applied dynamically, and quite trivially on top of that.
EDIT: Providing this information here in case someone is interested in implementing it. I now noticed that the issue is about client-side slowdowns but doing those optimizations would help on both sides.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants