I’m adding particles, using standard particle emitter and using the standard particle shader.
But my particles have a haze around them.
All of the particles have this glow around them. Any ideas what this might be??? I’m assuming it is a setting because many things end up with this glow and I’ve not figured it out.
It does look like the bloom filter. So anything in the scene that is very bright will get this glow.
If you actually want the bloom on your scene then changing its mode to “objects” as described above will effectively turn it off for your whole scene, though. But if you have bloom on for a reason then that’s probably not what you want.
Thanks. That was it.
That brings up many more questions about JME and Shader architecture. I open a new forum on that one.
I mean, ok. But this doesn’t really have much to do with that.
A whole screen effect like bloom is going to operate on the whole screen. “Object mode” is a way to hack around it by rendering a separate full-screen pass that just renders the objects marked for glow.
But if you were using bloom on purpose and were surprised that things were glowing then I assumed you must have been using it for some other reason (punch up colors or whatever)… in which case turning off the “applies to everything” part is going to turn off why you were using it in the first place.
…but I don’t know what effect you wanted from bloom so I can’t say.
I meant the bloom to be on an object only. I wrote my own GLOW shader, this way I get the effect I wanted. I didn’t want it for the WHOLE screen. just certain objects.
I can control when the GLOW happens, don’t want it on all the time, also want to have many GLOW objects and with them being different in Color, Intesitfy and strobe effect. So I have a material that handles adjust all those values and the end result is that I have house that have windows.
That suppose to have a “TORCH”/“CANDLE” in the window, it will have a flicker, and also have a slight change in color from a yellow to red (ISH) colors to simulate fire. Then each house can have a specific time the “TORCH” is on meaning people are home inside the house. So at night the lights can come on, but not all of them on all the time. People have different hours and schedules.
Trying to give it “A LITTLE” appearance of a living city instead of a static one more cities come across like. Specially since things like that really do not affect FPS on my simple game, so it makes it feel a bit “LESS LONELY”.
Like minecraft, you have a HUGE world, but until recent, it feels like your the “SOLE” survivor. That ends up boring after a bit. They have been doing good increasing the “LIVING” feel.
Thanks for all the help.
So it sounds like you rewrote the object mode of the existing bloom shader. It does what you describe.
Basically, set the bloom filter to glow mode and then on each object that you want glow you turn it on in their material, even controlling the color of the glow.
You might try to take it apart to see if there is anything your shader might use from it.
Where it changes from JME version of the glow is in the coloring…
vec4 color = m_GlowColor;
gl_FragColor = texture2D(m_GlowMap, texCoord) * color;
Where mine
vec4 color = m_GlowColor;
textColor = texture2D(m_GlowMap, texCoord);
float mixture = 0.4;
if (color.rgb == vec3(0,0,0))
discard;
else if (textColor.r > 0.1 || textColor.g > 0.1 || textColor.g > 0.1)
gl_FragColor = mix(textColor, color, mixture);
They are very close to doing the same.
Note: for future reference, if the glow shader is all you’ve changed then j3md files can specify their own glow techniques and use whatever frag they want.
Anyway, some potential simplification for your code.
First, if m_GlowColor is being set by code then the code maybe knows when it’s setting 0,0,0 and could then potentially use a boolean + define instead to turn it off. It’s just that an == comparison on floating point always raises a red flag for me because if it’s expected the m_GlowColor is a calculated value that might be 0 then a comparison < some epsilon is usually more appropriate. Probably not an issue in your case. And either way, you could discard before doing the texture lookup though it may or may not actually skip it depending on how branching is implemented by a particular driver.
I think you could even bypass the boolean by connecting the m_GlowColor to a define and then just setting GlowColor to null to turn off glow. Put GLOW_COLOR : m_GlowColor in the defines section of the .j3md then use #ifdef or #ifndef:
Actually, looking at the source code, JME’s glow.frag does exactly that except returns 0,0,0 instead of doing a discard. Which for its case is correct since non-glow objects should obscure glowing ones.
For things like this:
if (textColor.r > 0.1 || textColor.g > 0.1 || textColor.g > 0.1)
It can be more compact to do:
if( length(textColor.rgb > 0.1 )
…or if the potential for the sqrt gives you heartburn:
if( dot(textColor.rgb, textColor.rgb) > 0.01 )
Not necessarily faster, just more compact and less chance for one 0.1 to be typoed to something else someday.
…also for the record, the ‘else’ hardly matters with the discard right above it. 
Anyway, that being said, my own shader code is usually ends up messy in the end precisely from the trial and error to get it working and then fear of ever touching it again. But still.
I know that feeling.
I didn’t put the full shader and copy/pasted only the code that did anything but there are defines from the j3md file that uses ‘HAS_GLOWCOLOR’
Thanks for several pointers, I made most of those changes. I don’t use common shaders for the 3D space, I have my own shader for that, I use different lighting since my game is based on entirely QUADS, so shadow and shading doesn’t work correctly. Also, wanted to the shading to be more like a 80s game and not better lighting that is common is games today.