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

Particle Lag bug #94

Closed
DudeMcDude opened this issue Aug 11, 2015 · 7 comments
Closed

Particle Lag bug #94

DudeMcDude opened this issue Aug 11, 2015 · 7 comments
Assignees
Milestone

Comments

@DudeMcDude
Copy link
Contributor

Hypothesis:
http://www.co8.org/forum/showpost.php?p=100917&postcount=30

@DudeMcDude DudeMcDude added this to the Release v1.1 / Nice to have for v1.0 milestone Aug 11, 2015
@shartte
Copy link
Contributor

shartte commented Oct 1, 2015

Pinging @DudeMcDude
Is this resolved by my sector cache fix?

@DudeMcDude
Copy link
Contributor Author

No
In GF's computer, just had a lock up more than 20 minutes (!!!) in the fire node. In other words, same old.

This was after I left the computer running for about half an hour in the fire node, and then scrolled over. Classic node lag.

Was using GoG version since Co8 removed particle effects from critters, which (according to the above hypothesis) bypasses the problem.

@DudeMcDude
Copy link
Contributor Author

Ah, on second thought, the above may have been a device loss issue. I've had a surprisingly smooth sailing the second time around :p

edit: Ok, reverified node lag. I think it's the same issue you described for sectors, except applied for critters - if you wait a while and then scroll to a critter with pfx, it will lag (in proportion to how much time you waited with the critter off-screen or something like that).

@shartte
Copy link
Contributor

shartte commented Oct 2, 2015

that may actually then be the simulation issue. i thought i ironed that out, but i think i reverted the fix because the thing we actually looked at ended up being related to sector caching.

Do you have a save that I can use to reproduce this quickly?

@DudeMcDude
Copy link
Contributor Author

Here. Use the GOG version.

https://drive.google.com/open?id=0BzF5KfpDewVYS29WMTczNUhHbFk

Load the save, wait for a few minutes, and the scroll to top right direction. Should get a nice hang (more than a minute in my case).

@shartte shartte closed this as completed in da1cf55 Oct 3, 2015
@shartte
Copy link
Contributor

shartte commented Oct 3, 2015

Bug fixed. This should cause a general performance improvement where non-permanent particle systems on objects were involved.

@shartte
Copy link
Contributor

shartte commented Oct 3, 2015

Just an explanation for posterity (gave one in the commit message as well):

ToEE tracks lifetime for particle systems and their emitters separately.
While a particle system is off-screen, the lifetime of the system is increased, but not of it's emitters, because it needs to actually run the particle simulation to reliably increase that lifespan value.
The bug is this: ToEE checks the emitters lifetime's, not the particle systems when it tries to determine whether a particle system has expired.

Coupled with the fact that the animation system will keep spawning particle systems even for models that are offscreen, a huge number of particle systems will accumulate over time. Most of them actually dead. But as soon as you scroll them into view, ToEE will faithfully simulate all the emitters that now still have a lifetime of 0 until they expire. This causes a multi-second simulation loop.

The fix is simple, really: I now calculate the max. lifetime of the overall system and compare the system's lifetime against that value even if it's off screen. If the result of that check is that it has expired, i destroy the system immediately.

Effect: Instead of thousands of systems after a few minutes, the number of active particle systems in the fire node doesn't exceed 50.

@DudeMcDude DudeMcDude modified the milestones: Release v1.1, Release 1.0 Mar 29, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants