[SOLVED?] Filters on overlapping Viewports

Ali_RS · April 18, 2019, 4:55am

Nice finding.

I also have this black background issue when using filter post processors in my icon generator.

You can change it

jMonkeyEngine/jmonkeyengine/blob/2356320d3011955e3d73491111393f48261696cc/jme3-core/src/main/java/com/jme3/post/FilterPostProcessor.java#L542


      
          }

          

          /**

           * Sets the asset manager for this processor

           * @param assetManager

           */

          public void setAssetManager(AssetManager assetManager) {

              this.assetManager = assetManager;

          }

          

          public void setFrameBufferFormat(Format fbFormat) {

              this.fbFormat = fbFormat;

          }

          

          public void write(JmeExporter ex) throws IOException {

              OutputCapsule oc = ex.getCapsule(this);

              oc.write(numSamples, "numSamples", 0);

              oc.writeSavableArrayList(new ArrayList(filters), "filters", null);

          }

          

          public void read(JmeImporter im) throws IOException {

@pspeed, @RiccardoBlb, @sgold should we apply this tweaking into engine ? (I mean changing default value of fbFormat from Format.RGB111110F to
Format.RGBA8) both here:

github.com

jMonkeyEngine/jmonkeyengine/blob/2356320d3011955e3d73491111393f48261696cc/jme3-core/src/main/java/com/jme3/post/FilterPostProcessor.java#L87


      
          private float left;

          private float right;

          private float top;

          private int originalWidth;

          private int originalHeight;

          private int lastFilterIndex = -1;

          private boolean cameraInit = false;

          private boolean multiView = false;

          private AppProfiler prof;

          

          private Format fbFormat = Format.RGB111110F;

          private Format depthFormat = Format.Depth;

          

          /**

           * Create a FilterProcessor 

           * @param assetManager the assetManager

           */

          public FilterPostProcessor(AssetManager assetManager) {

              this.assetManager = assetManager;

          }

and here:

github.com

jMonkeyEngine/jmonkeyengine/blob/2356320d3011955e3d73491111393f48261696cc/jme3-core/src/main/java/com/jme3/post/FilterPostProcessor.java#L148


      
          }

          

          public void initialize(RenderManager rm, ViewPort vp) {

              renderManager = rm;

              renderer = rm.getRenderer();

              viewPort = vp;

              fsQuad = new Picture("filter full screen quad");

              fsQuad.setWidth(1);

              fsQuad.setHeight(1);

          

              if (!renderer.getCaps().contains(Caps.PackedFloatTexture)) {

                  if (!renderer.getCaps().contains(Caps.FloatTexture)) {

                      fbFormat = Format.RGB8;

                  } else {

                      fbFormat = Format.RGB16F;

                  }

              }

              

              Camera cam = vp.getCamera();

          

              //save view port diensions

rufsketch1 · April 18, 2019, 5:32am

Oh, huh. Not sure how I missed that.

I don’t think having the default format use the alpha channel is the right approach (it would require more memory, wouldn’t it?). But I think some sort of “allowTransparent(boolean)” function to implicitly let the user know it can be done might be helpful. (Clearly something wasn’t made sufficiently obvious if this many people had to work around it for this long).

sgold · April 18, 2019, 9:13am

I remember tripping over this gotcha when I was working on SkyControl back in 2017. The default format for FilterPostProcessor changed between JME 3.0 and 3.1, breaking my off-screen renders:
Porting tips - jME 3.0 to jME 3.1
Used R11G11B10F instead of RGB10_A2 for framebuffer format in Filters… · jMonkeyEngine/jmonkeyengine@200c875 · GitHub

RGB111110F uses the same amount of memory (4 bytes per pixel) as RGBA8. It’s not supported by all platforms. Its only advantage is greater color precision. I’d support changing the default format in FilterPostProcessor back to RGBA8.

RiccardoBlb · April 18, 2019, 9:20am

I haven’t read the whole post, but i don’t support this change.
This would trade precision for an extra channel that is unused in most cases, more precision is always an added benefit when rendering colors, alpha is only used by very specific filters, that’s why i think the current default is fine.

RiccardoBlb · April 18, 2019, 9:56am

Actually, why are you even doing this with multiple textures? You can just render the gui over the scene framebuffer and apply a single bloom pass to everything, processing the entire screen multiple times is very slow expecially at high resolutions.

rufsketch1 · April 18, 2019, 9:59am

Because then the handles would also get blurred by the Depth of Field filter. No one wants blurry handles.

RiccardoBlb · April 18, 2019, 10:01am

You can apply the dof before rendering the gui

rufsketch1 · April 18, 2019, 10:04am

How would I do the following:

Render a bunch of stuff that isn’t affected by dof (group A) .
Render a bunch of stuff that is affected by dof (group B) on top of group A.
Render a bunch of stuff that is not affected by dof (group C) on top of group B?

processing the entire screen multiple times is very slow expecially at high resolutions.

That’s fine for my purposes. Most of the time the user won’t be relying on a high framerate. They’ll be looking at a single image they draw on top of.

RiccardoBlb · April 18, 2019, 10:11am

render B (i assume your scene)
apply DOF
render A (with depth testing)
clear depth
render C
bloom

Something like this should work.

I see, in your use case it seems fine then, but usually there are better approach than multipass alpha blending, that’s another reason in my opinion why the opaque format should be the default choice.

rufsketch1 · April 18, 2019, 10:17am

B is blurred, so using the depth before would mean either the blurry portions of B get occluded by A, or they completely occlude A. But the desired behavior is for them to partially blend over A in a way that takes into account the blurriness of B. (See the most recent video posted)

that’s another reason in my opinion why the opaque format should be the default choice.

I think you’re probably right on this point. My use case is admittedly weird. But I do think having the option and behavior be more explicit or documented somewhere would be a good thing.