Quick thoughts and question:
I'm currently working on adding FBO support to jME, (possibly removing or deprecating Pbuffer use in the process.) According to what I have studied, FBO does not require any special hardware and is only requires your opengl driver support it. According to one source, GeForce 256 and above should be able to support FBO. FBOs are faster because they do not require context switching and they support rendering directly to texture far more cleanly than Pbuffer which means less falling back to the slow copyTex method.
In any case, does anyone on here have any thoughts or wishes regarding FBO support in jME that they'd like to put out for me to consider as I work on the framework of FBO support? My current plan is to have a Target (placeholder name) object in jME that either specifies a Texture or a RenderBuffer. These Target objects will be attached to a TextureRenderer for processing. This would mean changing how you create a texture renderer and how you set one up, but using it should more or less stay the same.
Would this allow you to switch back and forth between Pbuffer, FBO, and potentially something custom in the future?
if FBO's are as supported as the documents are saying we shouldnt need pbuffers at all. until we know that for sure it would be nice to have a possibility of using pbuffers in some way i guess(and i know renanse has thought of that).
anyone know of the best way of finding this out? (like writing a mail to nvidia/ati or something 
)
i think this can bring fps in about all of the stuff i ever do(and old effects like bloom, water etc) to new heights! great thing
Darkfrog, I'm not sure what "something custom" means. I will definitely leave lwjgl Pbuffer support in there somewhere, but it may be something you have to explicitly create and use rather than a DisplaySystem created, API agnostic class. As MrCoder says, if the docs are right, there is not much reason left to use pbuffers (as long as the users have recent drivers, which is already an issue.)
I have nothing useful to say on this, except that when I read the blog someone (renanse?) linked to on the ZP+ algorithm, I also noticed the most recent post complaining about ATi FBO support: http://www.terathon.com/wiki/index.php?title=Blog. It doesn’t make much sense to me, but I thought it might to one of you guys 
Yep, definitely some possible issues with only using FBO wrt ATI cards. FBO is still faster and more versatile in many cases though, so having the ability to use both, or to fall back to pbuffer when support lacks in fbo is "a good thing"™ in my opinion.
Hi!
Any news on FBO support? I know v.11 supports it now, but is it already possible to render part of a scene to a RenderBuffer for offscreen use? Guess it IS possible using direct LWJGL calls but I'd like to avoid that
Or maybe offscreen use of RenderBuffers will not be supported by jME? I'd hate to have to use multiple pbuffers and switch context for half the fps…
Thanks 
Edit: If not already supported by jME, can you confirm a "nice" way to do it would be to add something like an OffScreenRenderer class (similar to TextureRenderer), with methods to grab the RenderBuffer content (using glReadPixels or something) and convert it to an image? Or maybe create a common parent to TextureRenderer and OffScreenRenderer (since most of the code should be the same)
Thx
If anyone's interested, my OffScreenRenderer works nicely.
It's mostly based on the TextureRenderer code, with of course different settings for the FBO/RBOs. At the moment there's only an additional method, getPixelData(), to retrieve an IntBuffer.
In order to be AWT/SWT independant, image creation is left outside (but utility methods could be made).
Still, I'd very much like to know if I've reinvented the wheel Thx!
I'd just like to throw out there that this process doesn't work on any mac I've used so far.
I guess it's often possible to revert to pbuffers when FBOs aren't supported by the graphic card or by the drivers.
If I'm not wrong, that's what jME should be doing with TextureRenderer (there's both LWJGLTextureRenderer, using FBO, and LWJGLPbufferTextureRenderer with the old pbuffer method), but the LWJGLDisplaySystem.createTextureRenderer() method always returns an LWJGLTextureRenderer instance. Easily changed though…
Thanks for the info though, I'll try in on my (very) old G4. I don't think its faithful ATI Rage128 Pro supports FBOs
The Librarian said:
If I'm not wrong, that's what jME should be doing with TextureRenderer (there's both LWJGLTextureRenderer, using FBO, and LWJGLPbufferTextureRenderer with the old pbuffer method), but the LWJGLDisplaySystem.createTextureRenderer() method always returns an LWJGLTextureRenderer instance. Easily changed though...
Oo, that's good information! I'm running out the door now, but when I get back I'll make that change and retry the demos. Thanks!
I'm trying to change LWJGLDisplaySystem.createTextureRenderer() so that it returns a LWJGLPbufferTextureRenderer instead of LWJGLTextureRenderer
public LWJGLPbufferTextureRenderer(int width, int height,
LWJGLRenderer parentRenderer, RenderTexture texture) {
What would i use for the RenderTexture parameter?
This is a known issue that we will try to find time to fix as soon as possible(a fallback to pbuffers or let it be configurable)
Good news
Still no answer to my question: is my (LWJGL)OffscreenRenderer useful, or redundant with something I'm not aware of, or is there a better way to implement the feature? Thx
Fungi said:
I'm trying to change LWJGLDisplaySystem.createTextureRenderer() so that it returns a LWJGLPbufferTextureRenderer instead of LWJGLTextureRenderer
public LWJGLPbufferTextureRenderer(int width, int height,