I used to be able to add lines to a highlight layer, I would love to be able to add lines to a glow layer. I have tried creating tubes instead of lines, but performance is much better with lines.
That is an old screenshot where lines were working on a highlight layer.
Maybe something changed, but is there anyway to make lines glow in 3.3.0+?
Pinging @sebavan
I ll take a look ASAP
Thank you!
The fix is in and will be available with the next nightly: Fix Effects on Lines and Sheen BRDF + low albedo BRDF by sebavan · Pull Request #6025 · BabylonJS/Babylon.js · GitHub
This playground should work right after the push: https://playground.babylonjs.com/#258JTK#2
You can notice the use of a customColorSelector as the material does not have an emissive property and we can not infer its color.
Awesome! Thank you!
That is fantastic. I now have glowing lines. Can I do the same with a Highlight Layer now as well? I tried using the customEmissiveColorSelector function but couldn’t get the same effect.
While I love the glow on the lines, it is a bit aggressive for Objects that are in front of the lines, you still see the glow on them.
A quick example image 
And a playground https://playground.babylonjs.com/#258JTK#3
Ping @sebavan
It is because you need to set to black the sphere, excluding it let the glow visible behind it by design:
https://playground.babylonjs.com/#258JTK#4
Ahhh I had no idea, beautiful!.
Thanks again!
Sorry for bringing this topic back to life, but as a quick Google search sent me here, and I ran into some unexpected behavior after messing with @sebavan 's first PG, I thought I’d document my observations here for the next visitor.
Apparently if one wants to only apply glow only on a certain line, one also needs to explicitly tell Babylon that the other lines should not glow. See this PG.
Bug, feature, or me approaching this the wrong way? 
Yup it is by design as you use the custom selector you control the colors end to end.
Fair enough @sebavan , but I find the default behavior confusing:
If the user doesn’t explicitly apply a default glow, the result can be hard to predict. See this modified playground. I haven’t look at the source code, but apparently if the callback doesn’t set the glow for a certain mesh, and if no glow value has been set yet for any mesh, the method processes the remaining meshes and at last, applies to unhandled meshes a ‘default’ glow that corresponds to the last applied glow. (That’s a mouthful, but have a look at the commented PG for a more visual explanation).
In Firefox, playing this PG over and over again tends to make line2 (and line2 only) flicker, which seems to support my theory.
The fix is simple enough on the user side (do not leave any mesh unhandled, and provide your own default behavior, like the example in the documentation suggests).
But wouldn’t it make sense to just have a default no-glow applied by the library instead, and only customize the behavior of the mesh that we want to see glow?
I just started learning how to make stuff glow, so it’s very much possible that I am missing some use cases where the current behavior is actually desirable. If so, I’m curious to hear what those may be 
Thanks!
I like the idea of a default, but I wonder how many ppl already relies on the propagation behavior which prevents a long list when you know the order or your meshes in the scene. I am not too fan on introducing a new behavior here as the workaround is quite simple, but I agree I should have thought of this when developing it 
That makes sense, no worries! The workaround is definitely simple enough, and our short discussion here should be sufficient to put the next confused user back on the right track
Thanks for the feedback and for all the hard work!
