Two FilterPostProcessors crash the renderer sometimes?

So I’ve been tracking down a very odd bug for a while now and the premise is this:

Sometimes on startup, when alt-tabbing or minimizing the game repeatedly the filters or the renderer will start to show a black screen instead of the scene and I haven’t found a way to revert back from it.

I’ve narrowed it down to two succesive filterpostprocessors causing the problem and have put together a test case below.

Engine version: 3.1.0 Beta 2

import com.jme3.math.ColorRGBA;

public class MCVE extends SimpleApplication {
	static MCVE app;
	public static void main(String args[]) {
		app = new MCVE();

	public void simpleInitApp() {
		FilterPostProcessor fpp=new FilterPostProcessor(assetManager);
		if(app.getContext().getSettings().getSamples() > 0)
		BloomFilter bloom = new BloomFilter(BloomFilter.GlowMode.Scene);
		FilterPostProcessor fpp2=new FilterPostProcessor(assetManager);
		if(app.getContext().getSettings().getSamples() > 0)
		BloomFilter bloom2 = new BloomFilter(BloomFilter.GlowMode.Scene);
    public void simpleUpdate(float tpf){}

You can trigger the black screen by either:

  • running the code as is and clicking the taskbar button very quickly

  • comment out the addFilter lines, which will make it display the black screen on startup

The background is set to be red so the difference should be fairly obvious.

Anyone has any idea what’s going on here? I don’t really know if this is an old or a new problem since I didn’t ever use twin fpps in older versions.

I’ve had that same problem using the bloom filter and SSAO filter for a LONG time. Probably since 3.0. I always assumed it was something I broke. I often get it when I debug a line in my code and it pauses the rendering temporarily.

Yeah it’s either my game start after loading or an alt-tab that causes it, so that would be on point. Good to know it’s not just me loosing my mind (since it kind of feels that way).

Interestingly though, leaving the processors empty causes it too somehow.

Don’t use 2 FilterPostProcessor. It’s not meant to work like this.
Use only one and add all the filters to it.

What? Why is there an option to add a million sceneprocessors then? Also why in general?

See the problem is that I have a fpp with no AA which handles the filters with no samples defined and the second one with the two bloom filters which need to be the first thing in a fpp otherwise they crash.

Yet I need to run stuff before the bloom filters so I’m kind of screwed otherwise.

You can have a million wives, yet when you have 2 at the same time, shit hits the fan…

  1. why 2 bloom filters?
  2. maybe we’d better try to fix this crash, which seems to be the origin of your issue.

Well that’s why it needs to be at the end.

Sigh, okay I’ll restructure this best as possible then.

Just maybe this should be mentioned in the docs somewhere, you know?

Hello wild programmer, this object can only be used as a singleton because reasons.

Yeah. well…that is known. This isn’t.

One stock one that slightly blooms the entire scene, then apollo’s mipmap based one to very heavily bloom objects.

Can’t really do that in a single one I think.

After some testing now, it appears that only the lens flare before the blooms breaks them. Something which I can be alright with running afterwards.

Because filter post processor is not the only kind of scene processor.

You can have all kinds of scene processors for a hundred different reasons. But filter post processor is designed to have one at a time.

What concerns me is the above which indicates that it may be a problem even with one.

No, I did the same thing and had two filter post processors. I put that code in a couple years ago from the tutorials and didn’t realize you shouldn’t have more than one. I’ve been working with this engine for years now and I always seem to find out something new. I switched my code around and i’ll make sure I don’t experience this problem anymore.

I’m pretty sure it is written somewhere on the wiki. I have been learning JME exclusively from there when I started and I remeber it was written somewhere. I think it was the nifty part but I’m not sure.

Something like viewPort.getFilterPostProcessor() would make it more obvious and the viewport would assign itself a fpp singleton internally. But can’t do that now for compatibility reasons obviously.

Hmm I really don’t recall reading any sort of note regarding this. I remember testing using two nifty processors one time which crashed spectacularly.

I guess you can never have two processors of the same class? Gotta test it on the shadow renderer too I guess.

Should we also add Spatial.getAnimationControl() and spatial.getSkeletonControl()… and Spatial.getPhysicsControl() and any of the hundreds and hundreds of other nicely decoupled things that require a little documentation and understanding before knowing that you should only have one at a time?

Or can we leave the abstractions in place and just educate users instead?

Hahah… you actually can with shadows… that’s the only way to have 2 lights casting shadows…But that’s really a particular case :p.
I realize it’s not clear, maybe this whole processor thing would need some love, but for now I’m just gonna add more doc in the java doc of the FPP.


Maybe just an exception from the addFilter method when you add two fpps? :stuck_out_tongue:

1 Like