Board index FlightGear Development Effects and shaders

Canvas:View development

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

Re: Canvas:View development

Postby Hooray » Wed Sep 13, 2017 9:14 pm

There is a new texture type called "canvas" that allows shaders to access any canvas texture via a texture unit, just like you'd access a normal texture from the hard drive.


FWIW, back in 2012, TheTom was contemplating to provide additional look-up methods, today, we still only have "canvas/by-index" - but we were also talking about some kind of "by-name" or "by-id" lookup.

Some of the original ideas can be found here: http://wiki.flightgear.org/Canvas_Prope ... ounting.29

Depending on the scheme you have in mind now, it would also be possible to add a dedicated placement for exposing a certain Canvas to the effects subsystem using a correspoding texture unit
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11114
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas:View development

Postby Icecode GL » Wed Sep 13, 2017 9:20 pm

FWIW, back in 2012, TheTom was contemplating to provide additional look-up methods, today, we still only have "canvas/by-index" - but we were also talking about some kind of "by-name" or "by-id" lookup.


CanvasMgr can already return a Canvas by name or id, I opted for name since the index can vary.

Depending on the scheme you have in mind now, it would also be possible to add a dedicated placement for exposing a certain Canvas to the effects subsystem using a correspoding texture unit


Yeah, that'd be another option. This is the "delicate link" I was talking about in earlier posts, so I'm open to any suggestions.
Icecode GL
 
Posts: 457
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Canvas:View development

Postby Hooray » Wed Sep 13, 2017 9:26 pm

Personally, I guess that making this explicit is better/safer - simply because a Canvas may disappear at any time, so a lookup by name may not be as safe as requiring the user to explicitly register a placement to expose a Canvas to the effects system

The reasoning here being that we ran into the same issue when ThomasS came up with a way to "stream" an arbitrary Canvas over httpd/mongoose "by index" - it's kinda fragile to do it this way, and fairly low-level, too.

Thus, I am inclined to favor an approach where addPlacement() is used to expose a Canvas to the effects system, which could also share some code with other features requiring access to a Canvas (think the streaming facility)

Besides, we may not want always expose all textures, but we may still want to have the option to do so at any time.

Apart from that, it is much easier to deal with inconsistencies gracefully if a placement is used, e..g if the texture is n/a, has been resized or whatever else - dealing just with a magic number (or even a name) may be too fragile to handle such challenges.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11114
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas:View development

Postby cyrfer » Thu Dec 14, 2017 2:17 pm

I would like to understand where this effort left off. The new features are critical for a project I am working on. I am experienced with OSG and OpenGL but not so much with Flightgear's architecture. I could do the work with some guidance, or support someone else to do the work. Please contact me to collaborate. :)

@Thorsten
@Hooray
@Icecode GL

Thanks,
-John.
cyrfer
 
Posts: 4
Joined: Thu Oct 05, 2017 6:02 am

Re: Canvas:View development

Postby Hooray » Thu Dec 14, 2017 9:30 pm

it is working as expected usign the default settings (no fancy shader/effect stuff or Rembrandt/ALS tested, yet), without any technical problems - it's a fairly minimal set of changes that add a getter method to the built-in FlightGear view-manager to calculate the camera specified view settings and use those to render to an FBO/RTT offscreen context, the corresponding image is then used by a custom Canvas::Element sub-class that makes the whole thing available as a conventional Canvas rendering "primitive" (analogous to paths, text and raster images). The only "input" (property) the new element actually needs is the view-number that is to be used for the off-screen camera - other than that, all standard Canvas::Element properties are supposed to work "as is".

Other than that, the only technical thing that came as a surprise is the fact that the camera needs to be explicitly updated by setting the element-specifiic update property to "update" the texture - otherwise, it would stay static. Not sure if that got sorted or not - but it wasn't much of a problem, I think we were using a timer based update loop to update the view.

From an architecture standpoint, this is primarily about understanding FlightGear Canvas system and its rendering primitives - if in doubt, see:

http://wiki.flightgear.org/Canvas_Development

Under the hood, it's a conventional RTT/FBO cam that is using standard OSG code.
For the FlightGear specific camera stuff, the built-in view manager is used to compute the view matrix: http://wiki.flightgear.org/View_manager

The summary is, there is working code that can be used "as is" - it's certainly much more compelling than just a proof-of-concept - I'd even say, it's basically "finished" - just not integrated (reviewed/discussed). However, Stuart offered to help with that, once the corresponding code is put up for review, even saying that it would not need to be "perfect" :mrgreen:

People able to patch/build SG/FG from source, ideally familiar with git and C++/OSG should get in touch with Icecode GL for the set of patches.
Please let me know if he should be n/a, so that I can share the patches here. My only request then would be that the people working with the code, actually do set up a public git repo with the corresponding patches, because this seems to be a recurring question/request ;-)
And obviously, it would be really helpful if you could help us update the wiki article accordingly, to document your journey/progress.

PS: What exactly is it that you are working on, cryfer ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11114
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 2 guests