Fix for FilterPostProcessor, Filter and Pass on Android

I was looking through the code trying to figure out why my OSRViewport works but Filters do not… and it seems to boil down to something that could be easily fixed.

In Filter’s init method:

[java]
public void init(Renderer renderer, int width, int height, Format textureFormat, Format depthBufferFormat, int numSamples, boolean renderDepth) {
Collection<Caps> caps = renderer.getCaps();
if (numSamples > 1 && caps.contains(Caps.FrameBufferMultisample) && caps.contains(Caps.OpenGL31)) {
renderFrameBuffer = new FrameBuffer(width, height, numSamples);
renderedTexture = new Texture2D(width, height, numSamples, textureFormat);
renderFrameBuffer.setDepthBuffer(depthBufferFormat); // <<<<<< THIS LINE
if (renderDepth) {
depthTexture = new Texture2D(width, height, numSamples, depthBufferFormat);
renderFrameBuffer.setDepthTexture(depthTexture);
}
} else {
renderFrameBuffer = new FrameBuffer(width, height, 1);
renderedTexture = new Texture2D(width, height, textureFormat);
renderFrameBuffer.setDepthBuffer(depthBufferFormat); // <<<<<< THIS LINE
if (renderDepth) {
depthTexture = new Texture2D(width, height, depthBufferFormat);
renderFrameBuffer.setDepthTexture(depthTexture);
}
}

        renderFrameBuffer.setColorTexture(renderedTexture);


    }

[/java]

These two lines should be inside of the if(renderDepth) check.

Now… I haven’t looked at all of the filters… actually very few of them… BUT! BloomFilter… does not require Depth… so… each of the Filter.Pass.init() methods need to be changed to look like this:


extractPass.init(renderManager.getRenderer(), screenWidth, screenHeight, Format.RGBA8, Format.Depth, 1, false);
extractPass.setPassMaterial(extractMat);

And they should work fine on Android. FXAA should as well.

Anyways… hope this helps… /wave

EH… I say Bloom doesn’t require Depth… actually, I have no clue if it does or not as I didn’t read through it very carefully. However, once the Filter class is fixed, a pseudo-Bloom Filter could be written that doesn’t require depth if the current one does.

Ok… there is a slightly bigger problem that resides in FilterPostProcessor… However… with slight modification, I have Bloom running on my tablet.

It’s slow as all fuck… but it works :wink:

The problem with FPP is in reshape…

The reshape method sets the Depth buffer whether or not the Filter requires one this is set on both:

[java]
//antialiasing on filters only supported in opengl 3 due to depth read problem
if (numSamples > 1 && caps.contains(Caps.FrameBufferMultisample)) {
renderFrameBufferMS = new FrameBuffer(width, height, numSamples);
if (caps.contains(Caps.OpenGL31)) {
Texture2D msColor = new Texture2D(width, height, numSamples, Format.RGBA8);
Texture2D msDepth = new Texture2D(width, height, numSamples, Format.Depth);
renderFrameBufferMS.setDepthTexture(msDepth); // <<<<< THIS LINE
renderFrameBufferMS.setColorTexture(msColor);
filterTexture = msColor;
depthTexture = msDepth;
} else {
renderFrameBufferMS.setDepthBuffer(Format.Depth); // <<<<< THIS LINE
renderFrameBufferMS.setColorBuffer(Format.RGBA8);
}
}
[/java]

Anyways… fix these two things and JME’s non-depth dependant Post Filter system works on Android

EDIT: My bad…

renderFilterChain has a few depth references that are unchecked as well.

I thinks the issue is more complicated than that, I think I moved the depth buffer thing in the filter because some drivers (on osx if I recall) complains about an incomplete framebuffer if you don’t set the depth buffer format or even if you don’t attach a texture. Note that it’s not because you don’t need depth in a texture that the buffer is not used when rendering.
I’ll check.

I can’t see how the code you pointed in FPP could affect android though, the first part need the ogl3.1 cap which is pretty unlikely you’ll find on android.

Do you have a crash when the depth format is set?

I never really looked into filters for android because the few that worked were ridiculously slow (even the colorOverlay…).

BTW the bloom filter doesn’t need the depth as far as I remember, I’ll check that out.

@nehon said: I thinks the issue is more complicated than that, I think I moved the depth buffer thing in the filter because some drivers (on osx if I recall) complains about an incomplete framebuffer if you don't set the depth buffer format or even if you don't attach a texture. Note that it's not because you don't need depth in a texture that the buffer is not used when rendering. I'll check.

I can’t see how the code you pointed in FPP could affect android though, the first part need the ogl3.1 cap which is pretty unlikely you’ll find on android.

Do you have a crash when the depth format is set?

I never really looked into filters for android because the few that worked were ridiculously slow (even the colorOverlay…).

BTW the bloom filter doesn’t need the depth as far as I remember, I’ll check that out.

It may have ended up that I had to specifically set requiresDepthAsTexture() to return false… but I’m fairly sure this was the case due to renderFilterChain method.

Yeah… you get an error only because Depth or DepthX Formats are not supported. Out of curiosity, is it possible to use a non-depth format? I want to say that it didn’t work… but thought I’d ask to double check.

The FX were slow, yes… but I’m pretty sure that these could be written specifically for Android (or hopefully mobile devices in general) to work at a fraction of the cost (EDIT: And a fraction of the awesomeness… but still). At least if it worked, it would open up some possibilities.

One possibility would be to do an OS check and exclude the depth buffer set if it is specific to Android. I think I ended up doing this with all off-screen render elements in the gui library.

If you guys can get theses filters to work, I would be very very grateful.

I have been struggle to get a proper bloom or glow shader for android working.

None of the once I want to use or tested actually produced anything worth including in a production game.

So, keep it up!

Thanks

@ndebruyn said: If you guys can get theses filters to work, I would be very very grateful.

I have been struggle to get a proper bloom or glow shader for android working.

None of the once I want to use or tested actually produced anything worth including in a production game.

So, keep it up!

Thanks

It works with very little change… however… slow was an understatement. The standard blue box ran at 4 fps on my transformer tablet. I’m pretty sure a minimal sample version using 4-6 texture lookups would create a passable bloom effect.

Okay it is easy for you to say.
The big problem for me is my limited knowledge of glsl shaders. And the basic understanding of how it works.
I have read through a few articles but for some reason my BRAIN just doesn’t want to compute… :facepalm:

Anyways, here is a same of what I got to work with the code @wezrule gave me:

It does not look so good:

@ndebruyn said: Okay it is easy for you to say. The big problem for me is my limited knowledge of glsl shaders. And the basic understanding of how it works. I have read through a few articles but for some reason my BRAIN just doesn't want to compute... :facepalm:

Anyways, here is a same of what I got to work with the code @wezrule gave me:

It does not look so good:

Rewriting the bloom material shaders would take some trial and error–figuring out a good trade off between nice effect and performance. I just meant that the fix to the FFP/Filter & Pass were pretty simple.

Yeah I do understand.
Thanks, and please, if you ever get something proper to work on android regarding this bloom/glow effect I would really appreciate some help with it.

1 Like

I’ll look into it.

1 Like

You are the man.
Thanks