Support for AutoRemove in DecalSet

This seems like a fairly trivial request

Can anyone think of a reason why DecalSet is not being treated like ParticleEmitter and SoundSource?

Bump.

If we use DecalSet as per the sample, and we give our decals a fixed lifespan, the decals will automatically be removed when they expire - but we end up with empty DecalSet objects stuck to our drawables. For the static world, that’s not horrible, but it is when we apply decals to things that can move.

Here’s a proposed patch for DecalSet to provide it with the same optional “AutoRemove” support as provided by ParticleEmitter. This patch has not been tested, but is a recreation of a recent implementation of the same solution, I’m fairly confident that the code is good.

DecalSet already has the capability for Decals to have a fixed lifespan - when they expire, they are automatically removed from the DecalSet. This is very similar to what happens with ParticleEmitter.
But DecalSet was missing the capability of itself being auto-removed when it “expires” (due to all its decals expiring / being removed).

When the last Decal is removed from a DecalSet, these changes allow the empty component to optionally destroy itself, “just like ParticleEmitter”, such that we don’t end up with empty DecalSet objects attached to our drawables.

https://www.dropbox.com/s/60fqo3kp761sxq7/DecalSet_AutoRemove.zip?dl=0

Do you know how git works? It’s easier reviewing the diff of squashed commits and to test a whole clone.

In the past, I have offered PR, and found it to be a less than satisfactory route, as it is not transparent, it is not search-friendly, and there is no guarantee that my work would be seen again.
Times, as they say, are changing, and I’m happy when the community is happy.

Linking to commits does not require issuing PRs, it does however require having a public repository.

I have a public fork, but I hate the fact that I have a fork, and I am not inclined to publish it as it implies, in my mind, that I have made substantial contributions to the codebase, and though I may be prolific, none of my changes :to date: are exactly ground-breaking…

There is likely a tiny bug in the sourcecode I posted…
The “extern” statement should be “inside the urho namespace”… not slightly by a few lines outside of it.
Just move that statement down a few lines, past “using namespace Urho3D” and you’re gold.