What happened to this stuff? http://www.jmonkeyengine.com/doc/com/jme/scene/state/BlendState.BlendEquation.html
It looks very useful. Why is min/max/subtract blending not supported? Rendertextures may be used to emulate this functionality, but thinking of particle effects where one mesh is overdrawing itself I can’t think of a workaround.
Could these things be added? Or are they already in there and I’m just to stupid to find them?
You can use whatever method you would like in the fragment shader… And I believe the particles use AlphaAdditive atm (which is still supported in BlendMode)
@t0neg0d said:
You can use whatever method you would like in the fragment shader... And I believe the particles use AlphaAdditive atm (which is still supported in BlendMode)
You can't get the current framebuffer value in a fragment shader to blend with it, so programmable blending is not possible. There is the NV_shader_framebuffer_fetch, which is not common as far as I can tell.
Rendering to a texture and sampling it at the same time sometimes works, but is not recommended and will most likely result in errors.
Recommended is a ping pong approach of using two rendertextures, which does not work when one mesh is overdrawing itself, like with particle emitters.
AlphaAdditive uses the BlendFunc, this has nothing to do the the blend equation. What I'm talking about is stuff like:
Blending using the minimum of destination color and source color.
Blending using the maximum of destination color and source color.
Blending using the source color minus the destination color.
The source color is the color which is computed by the fragment shader. The destination color is the color in the framebuffer.
And to make sure you understand, here is a jme3 snippet:
[java]case Off:
break;
case Additive:
glBlendFunc(GL_ONE, GL_ONE);
break;
case AlphaAdditive:
glBlendFunc(GL_SRC_ALPHA, GL_ONE);
break;
case Color:
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_COLOR);
break;
case Alpha:
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
break;
case PremultAlpha:
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
break;
case Modulate:
glBlendFunc(GL_DST_COLOR, GL_ZERO);
break;
case ModulateX2:
glBlendFunc(GL_DST_COLOR, GL_SRC_COLOR);
break;[/java]
What I'm looking for is glBlendEquation. Please read it up: http://www.opengl.org/sdk/docs/man/xhtml/glBlendEquation.xml
I sometimes miss it too. @momoko_fan would be able to tell us if the omission is deliberate or not.
We don’t support that afaik. But @Momoko_Fan could confirm, because I could have over looked something.
As for the reasons, I guess nobody needed this until now.
@Momoko_Fan what do you think,we could add this to the renderstate?
If there’s a real world scenario where it would be useful, then we can add it in some form.
I also think the other blend modes should be available.
I would also like the other depth test modes aswell 
Anders Riggelsen - Visual glBlendFunc and glBlendEquation Tool
Unfortunately this has no min/max blending, but you get the idea.
I think it’s great having those presets for blendfunc, but some more control over blending would be nice.
@kwando
Yeah, other depth test modes are definitely extremely useful, too. The choice between always and less equal is not enough.
So, let me ask again, why do you need these modes?
@Momoko_Fan I would like to have “greater equal” when rendering light volumes in deferred rendering. (the case when camera is inside the light voume)
@kwando said:
@Momoko_Fan I would like to have "greater equal" when rendering light volumes in deferred rendering. (the case when camera is inside the light voume)
If you look at this article: http://www.altdevblogaday.com/2011/08/08/stencil-buffer-optimisation-for-deferred-lights/
You don't actually need greater or equal for depth. Its faster just using the "less" mode. However there are other use cases I can think of for controlling the depth mode so it should be OK to add it (you can post a patch).
My question was aimed towards @cvlad who asked about the blend equation and other modes which are harder to add than the depth modes.
@Momoko_Fan i’d say the problem is that JME is masking some opengl features. What ever it’s used for if it’s in opengl, it might have some usage somewhere.
If the use of it is marginal, maybe we should think of a fall back that users could use to pass some rendering directive before the render occur, and not integrate it directly in the API.
1 Like
@Momoko_Fan
For some hard to describe yet fun effects, really. I mean how would I describe why I would need something basic, like a sin function, in something funky, like my electricity shaders. 
It’s really as @nehon said: The problem is not having those presets for blending, but being limited them.
Here’s a example of min blending on the brush to create this texture in gimp: http://forum.unity3d.com/attachment.php?attachmentid=34944&stc=1&d=1337864103
For this shader: http://homepages.uni-paderborn.de/cvlad/animated_font/WebPlayer/WebPlayer.html
It’s not to hard to imagine similiar stuff created in realtime.
@nehon said:
@Momoko_Fan i'd say the problem is that JME is masking some opengl features. What ever it's used for if it's in opengl, it might have some usage somewhere.
If the use of it is marginal, maybe we should think of a fall back that users could use to pass some rendering directive before the render occur, and not integrate it directly in the API.
If you need direct OpenGL access, if you absolutely need it, like in this case .. Just use it. Modify the engine, and there you go, you have it.
There are an infinite amount of things that have "marginal use", and we are not going to add them.
In this particular case, the additional blend features are very rarely used, and are not supported by OpenGL1. There's no fallback for these features, so if they are not supported, you cannot replicate their functionality in any other way.
I see. Thanks for considering it.
@Momoko_Fan said:
If you need direct OpenGL access, if you absolutely need it, like in this case .. Just use it. Modify the engine, and there you go, you have it.
There are an infinite amount of things that have "marginal use", and we are not going to add them.
In this particular case, the additional blend features are very rarely used, and are not supported by OpenGL1. There's no fallback for these features, so if they are not supported, you cannot replicate their functionality in any other way.
Rarely used does not mean never used.
That's why I suggested a generic and common way to pass GL directive for corner cases like this one.
Something like the AdditionalRenderState of material.
Hi, I made a pull request to add the support of glBlendEquation