Talk:Understanding Rembrandt
Jump to navigation
Jump to search
Interesting analysis, but then why can not merge Rembrandt, with the effects of ALS? As the frame rate could be still acceptable? It should be remembered that they are increasingly popular graphics card with 1K of processors and 4-6 GB of video memory ... It would be desirable to resolve this incongruity. --Abassign (talk) 22:34, 3 January 2015 (UTC)
- ALS and Rembrandt are two very different render framworks and approaches. It isn't easy to merge both aproaches to get them together. Thorsten can tell you in detail why it currently not possible to merge both. Beside even if graphic crads get better and better - that does not mean to waste ressources, just because some hardware can manage it.
- --HHS (talk) 09:08, 4 January 2015 (UTC)
- Instead of asking Thorsten to answer this over and over again, you could also run a forum search [1]. But even apart from technical differences, most people able to maintain Rembrandt are hesitant to touch it for other reasons (performance, maintenance, current integration etc). This has been discussed at great lengths on the devel list. --Hooray (talk) 10:50, 4 January 2015 (UTC)
- Unfortunately, although I program for 30 years in Java, Python, and only occasionally in C ++ I have never worked in programming OPEN-GL :( So I'm not an expert in this field, but the quality of the "light" with Rembrandt and at the same time the splendid work by Thorsten with ALS should be able to find a point of union! Eventually Rembrandt defines shadows and modulates the light species inside the aircraft and for a distance of about 50 meters (LOD high resolution). But, observing the buffers used by Rembrandt, i think, for example, that the sky is black, is it possible to added ther ALS Sky ? If I'm not mistaken, then through a subsequent step (pipe?). In this case it would be possible to enter the magnificent sky and clouds generated by "ALS"? this would have a significant improvement in the image quality. My idea would be to add to the base drawing generated with a layer obtained by Rembrandt "ALS" mapping it with a boolean function. I also note that the buffer "Space- emission "seems to be able to perceive a good starting point. The areas below a certain level of light could be attributable to "ALS", while those bright Rembrandt.
Obviously we do not look too much to the performance, at the moment we try to understand :)! However, with the evolution of graphics cards already is now possible, in my opinion, having reduced performance still decent.--Abassign (talk) 16:01, 4 January 2015 (UTC)
- FWIW, we've had numerous discussions about Rembrandt vs. ALS and why Rembrandt maintenance is comparatively different/difficult:
- * http://forum.flightgear.org/viewtopic.php?f=37&t=24288&p=220985&hilit=#p220960
- * http://forum.flightgear.org/viewtopic.php?f=37&t=24288&p=220985&hilit=#p220984
- * http://forum.flightgear.org/viewtopic.php?f=37&t=24288&p=220985&hilit=#p220985
- * http://forum.flightgear.org/viewtopic.php?f=37&t=24288&hilit=&start=30#p221015
- Frederic Bouvier, the author of the Rembrandt Render wrote really good wiki article - it explains how it works in detail: http://wiki.flightgear.org/Rembrandt. You should look into. Unfortunately it don't describe how we get the manpower to develope this renderer further.
- Btw: I wonder why we have another page about Rembrandt in this wiki ??
- --HHS (talk) 16:23, 4 January 2015 (UTC)
- This article originated roughly a year ago when Thorsten and I were interested in exploring/understanding Rembrandt performance issue - the exchange back then was relatively fruitful for a few days, but we subsequently moved on to other things/projects. However, it seemed that some of this might be of interest to others, so I asked Thorsten whether we could move this to the wiki, where others could decide if they wanted to do more troubleshooting and use any of this (or not). And given how a few contributors (like yourself and i4dnf) are keeping an eye on the main Rembrandt article, seemingly waiting for any controversial additions, I took the liberty to move this discussion to a separate article -especially given that this doesn't quite match the quality of the Rembrandt article itself, where FredB spent quite some time getting things into shape.
- Regarding the whole ALS/Rembrandt issue, I really invite the OP to read up on the forum on all the differences involved here to appreciate the difficulties in "merging" things, plenty has been said about this - and anything posted by Thorsten and/or Fred should be considered authoritative. As was mentioned in this article, it would be a good idea to also read the technical paper that FredB used for the reference implementation in FG.
- Otherwise, I'd just like to note that maintaining Rembrandt -not to mention developing/merging Rembrandt, requires not just OpenGL and C++ expertise, but also a strong background in OSG and SG/FG, as well as 3D math and a solid understanding of 3D rendering in general, including the effects/shader framework.
- For the time being, Thorsten is the only contributor to take any visible interest in most of these areas, while others are either busy with other aspects of FG, or simply prefer to be lurking instead for other reasons.
- Even regardless of Rembrandt's status in FlightGear, deferred rendering in FG will surely gain momentum again sooner or later - we have a number of more or less overlapping efforts where similar building blocks are required that would also make deferred rendering possible at some point, without necessarily being specific to the existing/hard-coded implementation.
- Overall, it is a good idea to read the Rembrandt article and its reference section to appreciate the scope/design of the existing implementation. When it comes to ALS, Thorsten is obviously in the best position to judge how difficult porting/merging really is, and like he's repeatedly stated, he simply doesn't take any interest in Rembrandt for now due to a number of issues, many of which have been previously mentioned (including lack of performance).
- Personally, I don't necessarily see manpower being the primary bottleneck when it comes to Rembrandt - there's simply too much involved technically to expect newcomers to pick up Rembrandt maintenance/development - even OpenGL experts would need to learn a lot about SG/FG and OSG to understand the existing implementation, not to mention to continue development.
- So the main problem seems to be that Fred provided an excellent article for aircraft developers from an integration standpoint, without also documenting things for other core developers (which generally is a weakness of the project as a whole) - normally, that doesn't matter too much as long as core developers stay around, but in this case there's simply a technology "lock-in", because Fred already was an enormously experienced FG contributor with a track record in 3D related developments, which is what probably put him in a position to actually implement Rembrandt, without also realizing that there are only 2 other FG developers able to do similar work. So with him taking a hiatus, there isn't anybody remaining who's sufficiently experienced, and motivated, to explore continuing Rembrandt development.
- Admittedly, this is a chicken/egg problem, because I do know at least two coders who /might/ be interested if Rembrandt provided much better performance. As has been said, it could be that there are some trivial bugs in the existing implementation causing slownesss for many - but so far, nobody has stepped up to really debug/profile and troubleshoot Rembrandt, or even just document its internals.
- And unfortunately, some of the architectural pillars of Rembrandt are also not exactly well documented from a core standpoint (think effects framework).
- Again, I have no doubt that deferred rendering/lighting will eventually gain momentum again, even if nobody should show up to help with Rembrandt matters.
- In the meantime, the best thing people can do to ensure that Rembrandt will not just linger around, is trying to improve the current state of affairs, e.g. by documenting internals and by documenting any profiling/debugging to lower the barrier to entry. Still, I guess that Thorsten is among the top 3 candidates likely to take any interest in this, while also having the corresponding background - maybe in conjunction with i4dnf (which seems like an unlikely alliance...) or Zan.--Hooray (talk) 16:49, 4 January 2015 (UTC)
- I agree that it is necessary to define a new Wiki article where is possible to work by technical aspects of Rembrandt, because by the time lose the ability to evolve that code in line with developments of FGFS! In my experience of organizing IT projects believe that the Wiki is the best platform to achieve a shared document to which I also hope to contribute. I have read, a year ago, the Wiki article you mentioned, and the university publication on the method adopted, but now reread the article in the wiki, because, in the meantime, I have learned something more over OPEN-GL also about the wonderful work done on the current ALS. I'm used to, because my personal experience of work, to look, before writing or give directions on writing code for programmers, to assess what well the current code allows to do. In that, I have always noticed that rewriting the code already done, can be devastating! For example I am currently working in python on a system for automatically generate, on demand, the tile for osm2city (which I find another splendid job) but with the intention that run my program without changing the current work onosm2city. The reason for this approach is that anyone who is developing osm2city should not be "distracted" from the second-level developments that have nothing to do with his current job. I think this is the philosophy to be taken also to integrate ALS with Rembrandt, at least in the limit of the possible, if the performance will not be great, for the first phase, it is not a big problem, there are two possible developments: #1. Improve performance video card (as do our friends to work reasonably X_Plane 10.N) #2. Improving the code, but only if necessary and calmly ;)! --Abassign (talk) 17:26, 4 January 2015 (UTC)
- things are (much) more difficult than it seems at first - but I've started adding an Understanding_Rembrandt#Internals section to the article, which I am going to populate with related quotes/pointers over time to fill in some FG/SG related gaps. But the whole FG/project management side of this has been discussed at great lengths on the forum, i.e.:
|
If you want to see Rembrandt improved, the one thing that is missing is documentation for contributors wanting to get involved, it seems that contributors like i4dnf could help with that to some degree - but otherwise, even newcomers can do that - even if just involves the underlying building blocks, such as the rendering pipeline in general and the integration of the effects system - once those articles exist as stubs, we can grow them over time and fill in any gaps/findings.
|
|