Refactoring of framebuffer: Unified way to set render targets, added level field.

[riccardobl]

All the old methods are kept but deprecated.

[stephengold]

There are many places in the codebase where the deprecated methods are still used.

For instance, setDepthBuffer() is used in jme3-core, jme3-desktop, jme3-examples, and jme3-effects. But setDepthTarget() (its replacement) has no javadoc and is only used in a single example (TestMultiRenderTarget).

The shortage of examples (and javadoc) makes it difficult to understand how the replacement methods are meant to be used.

[MeFisto94]

It's difficult for me to write this paragraph, given that I didn't complain a year ago, but I've been using this API recently and had a few things I'd propose for potential changes.

1. Remove the FrameBuffer prefix from inner classes, preventing things like FrameBuffer.FrameBufferTextureTarget adding verbosity.
2. get/set/add: If you can get specific buffers and set used to overwrite the old one, can we maybe add an api to overwrite specific targets (if that is even supported / makes sense?)
3. FrameBufferTarget.newTarget and the private constructors. When I search for RenderBuffers and find e.g. the FrameBuffer.TextureTarget, then I probably expect to construct it via new TextureTarget, or at the very least with a TextureTargetFactory or -Builder. In this case however, it's not justified to require some complex factory, given that we only look at one simple parameter each. I understand that someone may want a convenience method to pick the right class based on the parameter, so one does not need to call new on the class, but I don't understand preventing regular use.

Now the problem is that this is already part of 3.4, but what do you think of it in general?

[stephengold]

Is the final question addressed to me, to @riccardobl, or to both of us?

[MeFisto94]

to everyone of jme. Especially depending on if it's just me or not