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.app.SimpleApplication;
import com.jme3.math.ColorRGBA;
import com.jme3.post.FilterPostProcessor;
import com.jme3.post.filters.BloomFilter;
public class MCVE extends SimpleApplication {
static MCVE app;
public static void main(String args[]) {
app = new MCVE();
app.start();
}
@Override
public void simpleInitApp() {
viewPort.setBackgroundColor(ColorRGBA.Red);
flyCam.setEnabled(false);
FilterPostProcessor fpp=new FilterPostProcessor(assetManager);
if(app.getContext().getSettings().getSamples() > 0)
fpp.setNumSamples(app.getContext().getSettings().getSamples());
BloomFilter bloom = new BloomFilter(BloomFilter.GlowMode.Scene);
bloom.setBloomIntensity(0.5f);
bloom.setBlurScale(0.5f);
fpp.addFilter(bloom);
FilterPostProcessor fpp2=new FilterPostProcessor(assetManager);
if(app.getContext().getSettings().getSamples() > 0)
fpp2.setNumSamples(app.getContext().getSettings().getSamples());
BloomFilter bloom2 = new BloomFilter(BloomFilter.GlowMode.Scene);
bloom2.setBloomIntensity(0.5f);
bloom2.setBlurScale(0.5f);
fpp2.addFilter(bloom2);
viewPort.addProcessor(fpp);
viewPort.addProcessor(fpp2);
}
@Override
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.
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.
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.
