Thorsten wrote in Sat Nov 05, 2016 7:54 am:If a canvas is internally referencable as a texture, it ought to be possible to dynamically also generate normal and reflection maps, no? And this ought to be a path to solve the feature request to provide the option to change such maps along with the livery?
That sounds like it should work, but I don't know enough about the requirements for such a normal/reflection map ?
But actually, a Canvas really
is a texture, it's a Texture2D object that has a bunch of listeners/callbacks registered that deal with texture related events (think size, background color etc) - and from then on, everything else is handled by "elements" (images, text, paths).
So the top-level primitive is a Canvas, which is just a property-enabled osg::Texture2D, so that the RTT can be updated "on the fly"
without having to exit/restart fgfs or patch any C++ code.
The screenshow that I posted a few years ago showing the Canvas-driven airports/taxiway dialog was registering the corresponding Canvas with the materials manager, so that the effects/shader machinery would become accessible, I think I got in touch with you to ask about adapting some effects for testing:
http://wiki.flightgear.org/Canvas_Devel ... 2F_ShadersObviously, this would work both ways, i.e. we could implement "chains" of materials where some are the input for a Canvas texture, while others are the "output" of a Canvas texture - which would mean that even schemes like Rembrandt (deferred rendering) could be implemented largely in fgdata space (effects/shaders, for the time being, Rembrandt is using C++ code to set up the corresponding buffers and stages to put everything together, because there really is zero Nasal overhead involved as long as only Canvas stage is used, i.e. none of the elements (an empty Canvas referencing a material created by another Canvas/effect).
And that point, you could have a multi-stage, and multi-pass, rendering pipeline implemented solely on top of the FlightGear property tree, by setting up a handful of "buffers" (Canvas FBOs/RTTs) and using them in a "creative" way to chain them together and create the final output.
Also note that we're talking here about roughly 50-100 lines of C++ code to teach the materials manager to retrieve a texture from the Canvas subsystem (instead of the base package) - ThomasS recently implemented the code for the Canvas specific side of this, because he also required hooks to get a Canvas as an osg::Image - so that he could serve it via http (i.e. as a jpeg/png):
The Canvas C++ code already has a getTexture2D() callback that we can use.
Also, another thought in a similar vein: How does canvas manage memory? If I declare a 20kx20k canvas and put just a few small raster images on it - do we need the full memory space of the 20k texture, or is there cleverness applied by dispatching lookup calls to the smaller texture (which likely costs extra performance, but hey...)?
Not sure what exaxctly you have in mind: It's a conventional OSG texture that is allocated - I doubt that any clever schemes are currently being used to preserve memory - but if OSG has any corresponding functionality, it could certainly be used by the Canvas system, I just don't think it's currently being done that way.
However, the Canvas image element already supports texture mapping, i.e. you can treat a raster image (including another Canvas) as the source for a raster image, and only get a portion out of it:
http://wiki.flightgear.org/Howto:Using_ ... xture_MapsOnce you stop manipulating a Canvas in the tree (and especially its child elements), it's all native C++ code that is running - i.e. no Nasal or property overhead once the corresponding data structures are set up, but that only holds true until the next "update", at which point everything is removed, re-parsed and updated/re-drawn (like you said in the other thread about rendering starting usually fresh).