[SOLVED?] Filters on overlapping Viewports


#21

Nice finding.

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

You can change it

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

and here:


#22

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).


#23

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
https://github.com/jMonkeyEngine/jmonkeyengine/commit/200c875ba2e0864a1001a8a69b94c2f0d4f90414#diff-d6208d45d370d057a9ecdd2b83569f9a

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.


#24

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.


#25

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.


#26

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


#27

You can apply the dof before rendering the gui


#28

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.


#29
  • 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.


#30

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.