Correct. The lower the gloss (i.e. the rougher the material) the more the energy will be distributed (and, currently, lost. that may change, however, in a little while.).
- Jaggy edges for lights (light material & vray lights) can be lessened with a softbox texture with frame mode active (see https://forums.chaosgroup.com/forum/…55#post1106055)
Correct, surely for square area lights. Ofc with lightMtl it will depend on the mesh’s UVs.
- Set vraylight to invisible for specular iirc
It may not apply anymore, as reflection and specular are now slightly different, under the hood, than they were.
It may help, surely, reducing long rendertimes if the specular was very hot, but it will also lose the specular altogether.
Use with caution. 
Render settings
- Tweak max ray intensity to lower values
Yes and no. MRI works well for GI, not so much for reflections, which are often where fireflies generate from.
I generally have it off entirely, and rather prefer to use, say, a second clamped version of the HDRI in a dome for reflections/specular, so that i have more control.
- Increase retrace value
This will chiefly help with light leaks and stability of the GI solution in animations.
It may also help in some specific case with reflections, but am unsure if it would help for fireflies.
- Increase image filter size (between 2-4.5px)
Umh, i wouldn’t, at least for fireflies.
It has a potentially big performance impact, regardless of what is being rendered, depending on the filter type.
But a bigger kernel size will always render slower.
There’s a chance it’d also “splat”/“blur” the fireflies, making removing them in post (more of this further down) difficult or outright impossible.
It would however surely reduce edge crawling across animations, through softening the image. (I assume no one uses sharpening filters anymore.)
I could add two points here about sampling.
*) Max subdivs for the sampler:
We’ve seen instances of incredibly high sampling (like, 256. That is 256 rays *squared*, or 65k camera rays per pixel. Plus the secondaries, by default some 393k rays per pixel.) used to cure exceptionally bright HDRs (like, +inf) which would cause leftover specs at lower sampling.
That is doable, but *exceptionally* expensive to compute.
If 100 max subdivs leave noise, it’s *extremely* more convenient to make changes to the scene (the earlier, the better, so the changes in look can be taken care of before the approval process begins.) than to just crank AA up and send it to render, be it a still or an animation.
You’ll thank me when no buckets will stick for a day or two. 
*) Use the SampleRate and NoiseLevel REs *as early as possible*.
And keep referring to them to find out which part is taking up the rendertime as you build up the scene and lookdev the shaders.
At the very least, it’ll save you from nasty surprises come rendertime (ofc, for sequences, do “sample” renders of specific frames.), and in the best cases it will catch out some mistake and allow for a fix.
Lighting
- If using a HDRI clamp it (see https://forums.chaosgroup.com/forum/…44#post1122744)
Correct. This kind of clamping, however, won’t respect the original hues (say, a yellow/orange sun disk), so the parts to be clamped *should* be sampled, and the clamping color adjusted to match its hue.
It can be done in post, or through rendering the HDR as environment map, in the VFB itself.
- If using Vray sun make it invisible (for example for VRayCarPaintMtl)
Correct, and a very good idea in general: no one will see the sun disk anyway, most of the time, as the glare in the atmosphere will cover it.
The disk itself can go to around 3 million float, depending on time of day, while being *very* small in angular size (i.e. its size projected over the sky dome).
And we know that very intense, and very hard to find, light fixtures will produce fireflies.
Denoiser
- Intel denoiser is better at filtering bad pixels
Yes, but it -yet- doesn’t do a very good job on some other details.
It also shares the same issue as the post methods below.
- Post denoiser with more frames?
If fireflies are individual pixels, or very small clumps (say, two to five), then it’s trivial to write a firefly remover in post. (attached, the one i made years ago for nuke. It comes without support, though.).
However, i have yet to see anything able to do a good job with bigger clumps.
Feel free to apply my gizmo multiple times to the same image/sequence, as it will remove progressively more fireflies, each time.
At some point, however, it will run out of luck (read: data to fill in the firefly pixels with.), and produce varying degrees of garbage.
In general, if i was to think of an overarching guideline, i’d go for “be frugal, stay in control”.
Don’t make lights needlessly small or needlessly intense, shaders needlessly sharp and needlessly bright, motion needlessly quick, and ultimately, sampling needlessly high.
And *always* use the diagnostic REs to figure out what is happening to the scene as soon as possible in the production process.
FireFlies Killer.zip (4.63 KB)