iT2D 1.4 Beta 2 (and 1.4.1, and 1.5) - particles stop playing when off camera - LOGGED

#1 particles actually should stop updating when no longer being in view.
Don't see a problem with this.

where I would see a problem is if the particles don't simulate the "time passed" between them going inactive and getting active again if they come back into view range, as that naturally would be the expected thing to happen so that they visually "never were paused"

#2 Here's a picture to illustrate why this is a bug.


Aircraft in my game leave a trail of dots formed by a particle system. The player can move the camera by dragging their finger on the iPad. If they pan the camera such that the plane leaves the edge of the view (and with it, the particle emitter) the entire particle system, including all the dots which are still on-screen, vanishes immediately. There is no way to get these lost particles back.

I understand that this optimization was added with good intentions, however it was a mistake. It creates more problems than it solves and needs to be removed. Particles must not stop updating or drawing when their emitter has left the view.

#3 Rather than logging this as a bug, as it is an intended optimization, I'm going to see if this optimization can be isolated and create a flag for the particle effect. If this happens, I will log it as a feature request instead.

#4 Please do not try to fix this bug by adding additional features or work-arounds.

Hacks piled upon hacks do not make for a good engine.

It was a mistake to add this optimization.

Here's a further example of why this optimization is totally useless and must be regarded as a bug:

I have a smoke particle effect playing to represent a fire somewhere in the level. The camera moves such that this effect is off screen - so it automatically stops. How can I resume this effect when the camera returns? Should I check every particle effect's position relative to the camera on every frame? That's not efficient. Also, it's impossible to resume the effect as if it had been playing all along.

Now realize that this problem exists with EVERY particle effect in the game.

My only option with regard to this bug is to disable it in the source code (which thankfully is very easy) - but think about new users. They should not have to edit the engine source to get iT2D to work properly.

Now let's say that you actually DO want moving particle effects to stop when they travel outside a certain range. That functionality already exists with the onWorlLimit() callback. So this optimization is not even needed in the first place and is needlessly duplicating existing functionality.

I'm not trying to be rude by labeling this a bug, and I mean no disrespect to whoever added it. The simplest solution to the problems it raises is to just roll it back.

If there's anyone out there who actually finds this optimization to be beneficial can they please post an example here of how it is useful?

#5 I don't think that the actually intend optimization was a bug (particle system out of view)

all that needs to be done is that this optimization is fixed and correctly done.
Correct means that the particle system is:
1. Paused
2. when it is COMPLETELY out of view

it can't be that it starts to mess in while it is still rendering stuff on the screen.
That part is a thing I fully agree to be considered as a bug that needs to be handled.


And I agree on Conor's "don't hack the mess any further to hack in another feature"

TGE was full of hacks, TGB expanded upon this hacks and iTGB added further hacks.
What we have at the time is the likely most fragile and instable Torque engine that ever existed and I think that the next milestone should do what TGE did with 1.5: Focus on fixing and solidify it, make it do what it is meant to do and what it actually could do when it was allowed to do it due to not running into bugs while doing so.
1.4 was a good step forward, now it just needs to become rock solid or at least close to it.

#6 Marc - I agree that this optimization could be useful if it paused particles when totally out of view. However would it still be an optimization then?

Does the time gained by pausing particles off-camera outweigh the time lost by checking every particle's position relative to the camera on every frame. Perhaps it would in a simple game, but in a realistic situation with more than a few particles the cost would probably start to outweigh the benefit. My game has about 5 simple particle effects running at all times, and this peaks up to about 10 during combat. This all runs at a constant 45fps on the iPad with this optimization disabled.

#7 Yeah, it's extremely annoying. I'm no programmer, and by the description on garagegames.com it sounded as if "anyone" could create a game with T2D and iT2D. I've encountered a few difficulties/hinders with iT2D and this particle effect "bug" is one of them. Creating a TileMap/TileLayer and making it show in the Run game test is another story..

In what file do I disable this particle "bug" so that I can have objects with particle effects attached to them go off camera and back in, such as in the render I did in T2D with the fireflies here:

http://www.youtube.com/watch?v=4tfpZK6Qfts

#8 @Conor: Yes it would still be an optimization, a massive one actually.

The order of check should be the same as you do it in 3D against the view frustum for stuff:

1. pdate all particle positions in the particle system
2. if the new bound of the system isn't in view (so no overlap from its bounds with camera view bounds), stop here - mark all particles previously not marked as out of view as out of view and update their time markers
3. for each particle still in view, update the other attributes and render it
3.1 if a particle is not in view and this was the frame this was detected, set a time marker on it so its known when it was last updated
3.2 when such an out of view particle comes into view again, simulate all attribute changes since the stored time marker (get it up to date) and draw


Thats rather trivial if you ask me, it works correctly and its a hell a lot more performant cause the position update is pretty lightweight and the only thing required to find out if the particle system shall do anything or not.

Also the check done in 2 and 3 would allow occlusion testing so if a particle is completely behind a non blending sprite / tile layer it would also stop rendering for example.

Unsure on how it works at the time as I've never looked into it I've to say.

#9 Hmm, maybe a flag should be in the editor that toggles that on and off. I'll look into this today.

#10 OK. This is all related to the PUAP_OPTIMIZE preprocessor being defined. Defined, nothing renders or stays active if it starts out of camera view or leaves camera view. Particles flat disable and t2dSceneObjects will not render if any of its bounds extend beyond the camera.

This is indeed an optimization, but it was only implemented half way. From a usability perspective, finishing this optimization would mean adding a flag to an object in the scene to utilize this functionality. Honestly, past developers went a little crazy with all the preprocessor definitions. Even I have a hard time keeping track of what all they handle.

Before I attack start slinging code, I'll try a couple different approaches to determine what is the most intuitive way to handle this. It's not a hard fix by any means. If you want results immediately, remove the PUAP_OPTIMIZE definition from your project settings. This will get you going while we clean things up a bit.

#11 Perhaps the PUAP_OPTIMIZE flag should be off by default in new projects, until everything that responds to it is properly implemented. That way new users won't experience unexplained particle disappearances, and experienced users can turn the flag back on if they really need the performance and are willing to work around the issues it creates.

#12 @Conor - That's probably an excellent start. I'll go ahead and change that in case I can't get a clean implementation in before QA is finalized.

#13 This bug is still present in iT2D 1.4.1 and the PUAP_OPTIMIZE flag is still on by default.

#14 Logged as ITGB-145 (task)

I created a new ticket for this issue with a new action plan in mind.

#15 This bug is still present in iT2D 1.5 and the PUAP_OPTIMIZE flag is still on by default. Removing PUAP_OPTIMIZE from the preprocessor macros doesn't seem to have any adverse effects (so far).