Project Rembrandt: Difference between revisions

   |So, it's not really Rembrandt that's the issue here, the bottleneck is the number of active expert C++ developers (you cannot really touch the 3D parts of the simulator with "just" C++ knowledge, you also need strong maths skills and OpenGL/OSG 3D rendering experience), especially once they're no longer around to help integrate their code and if there's little documentation to help newcomers maintain their code, because that's when base package development is often taking over eventually.

   |For example, I think it's pretty safe to say that the Canvas system was never intended to "compete" with Rembrandt, and most people here will be wondering how it could possibly be competing at all ? But ultimately it really is an integration and accessiblity issue, too. Admitedly, you need to be familiar with the way the project works to foresee what could be happening here, but it's not really far-fetched at all:<br/>

I had a quick look, and according to the initial Rembrandt commits by FredB, they were all about decoupling rendering into multiple stages and doing offscreen rendering to textures. This is also supported by the wiki and the initial Rembrandt discussions on the devel list. So far, straightforward to understand - even without knowing any GLSL.<br/>

Rembrandt obviously predates the Canvas system, but these days that's exactly what the Canvas is good at: offscreen rendering to an osg::Image, without having to touch any C++ code, and without having to build FlightGear from source.<br/>

So consider a Canvas texture as the potential input/output for an effect, and there you have it: Canvas + effects/shader {{=}}&gt; one important ingredient for a Canvas-based Rembrandt port.  

Several years ago, Zan made lots of progress doing this sort of thing, long before the Canvas again - so it's also an integration issue.<br/>

These days, this would require the view_mgr code to be adapted and turned into a Canvas::Element. For example, see:<br/>

Other aircraft developers have asked for effects/GLSL being available to cockpit textures for other reasons, e.g. to implement night vision views/FLIR imagings. And supporting effects/shaders in Canvas has been discussed various times on the forum too.<br/>

So, these are just two new features: 1) making effects/GLSL usable to Canvas textures and 2) rendering scenery views - and suddenly you have two major ingredients for a deferred shading scheme in place, without requiring extensive C++ changes, and without necessarily having to even look at Rembrandt ...

   |I don't think that anybody is working on replacing Rembrandt, but I also don't think that we have any active core developers who could easily help maintain Rembrandt (except for FredB obviosuly) - still it is foreseeable that the Canvas system will -eventually- provide all essential building blocks to allow deferred rendering to be built on top, it's really just a matter of time.<br/>

At that point revisiting the Rembrandt code and moving its rendering stages into cascaded Canvas textures that make use of scenery views and effects/shaders with an osgViewer-based placement, would be straightforward for any GLSL developer, much more so than getting to grips with the underlying Rembrandt C++ code itself. <br/>

As we know, even for good ideas, it usually takes ~3-5 years for them to be implemented (remember: OSG port, Rembrandt, Canvas etc).<br/>

So I still wouldn't hold my breath. But re-considering the way Rembrandt is done and integrating it with the Canvas system would help make it less obscure and more accessible to effects/GLSL developers, especially for times when there are no C++/3D experts around.