Talk:Canvas development

Optimization brainstorming

• one osg::Geode per element, including groups, explore caching for non-dirty elements ?
• use OSG data structures for update/visibility handling, e.g. osg::Switch ?

Latest Batch of Rembrandt related Quotes (10/2014)

Mr Hooray, FYI, the only hardcoded part in Rembrandt is the shadowbuffer format. The rest of the pipeline is completely configurable (both buffers and their attachments). You can implement however many effects and whatever GLSL side. You'd know that if you'd at least bothered to read some of the articles you so readily deface with these quotes. Yes that means that most of your self-quoting is FUD.

P.S. feel free to ban me if you feel like it

I4dnf (talk) 22:02, 19 October 2014 (UTC)

Mr. i4dnf, please feel free to join F-JJTH's effort to help document Rembrandt internals properly - and yes, a few of us looked at its internals, and it seems you are also unaware of some issues there. So it would seem to make sense to contribute what you apparently know, I am sure we can grow a repository of Rembrandt related knowledge over time. Besides, you might want to reconsider the way your are participating here - speaking up on the wiki the way you tend to do, is not necessarily the most effective way to "participate" in discussions that have taken place elsewhere. Also, if someone is spreading FUD and making false claims, you could just post pointers to prove them wrong, which makes more sense than doing what you're doing here (regularly).

I don't think there's any reason to "ban" you, though - if you'd like to have your wiki account removed/disabled, please state so clearly - I am sure that your request will be accommodated promptly. But given that you are claiming I am wrong, I am really looking forward to seeing you joining F-JJTH's efforts to help better document Rembrandt internals though, so I would really hate seeing your account removed. --Hooray (talk) 08:37, 20 October 2014 (UTC)

How about I contribute as I deem fit, and I spend my time as I wish, since I, like you, am a volunteer. (sounds familiar ?)

The pages I was refering to are pretty well documented already, and should give you enough hints/ideas about how to proceed in setting up a different pipeline, using the result of some rembrandt stage into your own shader, etc.

If you need further consultancy, feel free to join IRC and look me up there, and I will see about accomodating your needs, once we reach a mutually convenient agreement.

I4dnf (talk) 09:00, 20 October 2014 (UTC)

wow, that must have been the single most-constructive response I've seen from you in years - so thanks for that (sincerely so)!

I really wasn't trying to tell you how to contribute or when to speak up - but like I said on the forum a number of times: we (the community as a whole) tend to discuss/debate issues at great lengths (often spanning several years) that could typically be solved much more efficiently -and quickly- by documenting what we know and getting others to join us, or by finding at least a common subset of interests.

I am not against Rembrandt at all, I also don't appreciatee it being de-facto "unmaintained" - I would very much like to see its development continued - but all the time "we" (again, as in the community) spend debating its pros&cons, would be much better spent by coming up with the required documentation, tutorials and examples to spread what we know.

Undoubtedly, you belong to the tiny camp of people more intimately familiar with Rembrandt and the FG rendering pipeline overall - so you are in a much better position to help with such issues than others are, including myself.

What I've stated so far, is based on looking at the commits, the C++ code and on playing with different settings - it is indeed intended to be a "summary", which is why there's so much "self-quoting" going on. It is intended to provide pointers and entry points, to help lower the barrier to entry for people interested in dabbling with related things.

If I am wrong, I really want to be corrected - but based on what we know, and based on what other core developers have discussed, I am probably not that much off (unfortunately). I know that you have stated that you typically don't read my responses or the quotes, but the discussion we've been having on the forum was specifically about generalizing the Rembrandt setup code (C++), such that the more obscure/difficult parts can be tackled by people who don't necessarily need to touch $FG_SRC/Viewer at all.

Zan's newcameras branch was mentioned a few times, and even Fred and Mathias were very interested in that back then, especially in the context of generalizing Rembrandt/alternate rendering schemes.

Like you and others -e.g. F-JJTH- have said a few times: maintaining the effects/GLSL side of Rembrandt is comparatively straightforward vs. maintaining/updating and optimizing the C++ integration layer. Which is why we've been discussing a few things behind the scenes - obviously, whoever is tackling this, is free to make up his/her own mind - but it wouldn't be fair not to mention related discussions/developments (like effects, CameraGroup, newcameras or Canvas and CompositeViewer). If Zan's work (or TheTom's Canvas) had been around prior to Rembrandt, FredB would have undoubtedly used those as building blocks for implementing the new Rembrandt pipeline - which would mean that Rembrandt development would not be affected by a lack of C++/rendering development. I am not saying this is the best or the only choice, it is just a natural development - without being specific to Rembrandt. Equally, we have other hard-coded features in the main/fixed pipeline like the skydome that could be moved to effects/GLSL space at some point, no matter if people like ALS or not: we have contributors wanting to disable/customize these hard-coded things, without having to touch any C++ code.

Speaking from experience, all of us tend to disagree with each other more often than we agree - but for some reasons discussions do not work out as well as wiki articles and "summaries", even if those are just incomplete stubs waiting to be extended over time, like Understanding Rembrandt or The FlightGear Rendering Pipeline.

The Canvas Development article is equally just a stub, despite being pretty sizable now, because it is just collecting related discussions, patches and developments, for people interested in doing similar things - there's a lot of stuff going on here that is never making it to the devel list for some reason, I've seen patches, screen shots and videos doing fancy things - and the project is generally not very good at lowering the barrier to entry for new developers. Thus, this article is really just a collection of pointers that is being cleaned up and updated over time. Equally, once/if a Rembrandt developer/maintainer should show up, that person may make up his own mind about past discussions, developments and patches - and either disregard all the previous ramblings, or maybe even find a few pointers interesting. --Hooray (talk) 09:51, 20 October 2014 (UTC)

PS: Just like you don't use the forum, I don't use IRC - thanks for the offer though. But given that it's primarily F-JJTH who wants to update the Rembrandt docs now, you should probably get in touch with him and maybe even team up (temporarily)?

Map Performance

Tests with both the UFO and thw 747-8 have shown this change to improve the performance of the ND with long routes activated, however long routes with only start and finish waypoints (like KOAK to EDDK) will still behave in the same way as before. — tikibar (Fri Dec 19). Re: Canvas ND performance issues with route-manager. (powered by Instant-Cquotes)

I would prefer to file a feature request so that the Canvas system will implicitly apply geo-based "clipping" (filtering) at the C++ level. We did once discuss this here - and it should be straightforward to implement according to what Tom said back then. — Hooray (Fri Dec 19). Re: Canvas ND performance issues with route-manager. (powered by Instant-Cquotes)

In the long term I would prefer to extend the underlying C++ code for doing smarter/faster geo-based filtering - the other obvious optimization here is that we don't necessarily need to redraw the whole route once the range changes, but only need to render the route once and apply different transformations (thinking zooming/offset). Conceptually, this would be possible to implement by using a separate Canvas for the route behind the scenes and referencing it via [canvas:// canvas://], which is the technique we're using for the built-in SymbolCache. So basically we could modify the code to render the route to a separate texture and then merely change the offset/zoom (=range) properties in the referenced canvasImage child, which should make these things much faster (that is, once the map is drawn once). Internally, the Canvas system should preferably still apply clipping to restrict drawing/updating to visible elements only. — Hooray (Fri Dec 19). Re: Canvas ND performance issues with route-manager. (powered by Instant-Cquotes)

it would be possible to make searchCmd() smarter by caching the resulting vector and only applying changes instead of re-drawing the whole route from scratch. I am sure that Philosopher and TheTom will have more/better ideas ... — Hooray (Fri Dec 19). Re: Canvas ND performance issues with route-manager. (powered by Instant-Cquotes)

Even a route spanning several continents could then be rendered to a single 512x512 texture, with the current position being simply a texture map lookup on the existing canvas - for the latter, it would help if the texture map coordinates could be specified as actual lat/lon tuples obviously — Hooray (Fri Dec 19). Re: Canvas ND performance issues with route-manager. (powered by Instant-Cquotes)