Thorsten wrote in Sat Oct 05, 2019 6:29 am:James (who has in actual reality been responsible for the OSG Earth patch review) isn't around
Actually, Stuart was the one originally involved in
the original osgEarth review, with James awaiting Stuart's feedback, because of his involvement in that portion of the simgear code (scenery)
Both, Stuart and James and others suggested that the osgEarth patches be committed, with the condition of everything being a compile-time switch at the time:
https://sourceforge.net/p/flightgear/ma ... /31901928/James wrote:I feel pretty strongly it needs to be a compile-time switch - partly I’m not really looking to deal with osgEarth deployment on Mac or Windows in the near future, and partly we have uses who do not want, or may not be able, to build osgEarth.
With Stuart's stating in January 2014 (aka, almost 6 years ago):
https://sourceforge.net/p/flightgear/ma ... /31885513/Stuart wrote:I've now done a further review of an updated merge
request, and I'm happy that it should be merged.
Now that the V3.0 code-freeze has passed, are there any objections to me
merging the code?
-Stuart
psadro_gm wrote in Wed Oct 23, 2019 8:55 pm:On linux, AGG only supports PPM. I may look if mapnik has integrated other image formats and how far they've diverged from the AGG source.
It's possible that canvas has similar capabilities as agg, but I'm sticking with agg for learning/prototyping, since it's so small and easy.
Just briefly, regarding your comments on Canvas vs PPM:
The Canvas system is really "just" a wrapper around existing OSG formats - i.e. it works such that there is a property-enabled layer on top of stuff like osg::Image, which maps property updates (SGPropertyChangeListener) to the corresponding OSG APIs of the object at hand.
Which is to say, it would be relatively easy to adapt/extend the Canvas system to support additional formats, including other raster images, but also GIS related data formats like ESRI shapefiles/GeoTiff etc.
James and Stuart both hinted at that repeatedly over the years, because such changes would not just be useful for anything involving our scenery, but also for any mapping/charting functionality (think moving map displays).
You can open $SG_SRC/Canvas, which is where you can find something called CanvasImage.?xx - which is the wrapper mapping an osg::Image to a simgear::canvas::Element.
There are also examples of non-OSG code adapted to work like this, e.g. ShivaVG serving as the renderer for anything involving OpenVG (Canvas.Path elements).
We also have experimental patches illustrating how to take arbitrary fgdata imagery and use that as photo-overlays:
http://wiki.flightgear.org/Photo_sceneryIn conjunction with how the Canvas system supports placing textures via so called "placements", it would be possible to adapt those patches and come up with a new dedicated "terrain-placement" that could use any Canvas texture and drape it over the terrain as needed - given how the Canvas system has helped boost avionics development by moving away from the core development bottleneck, and seeing how Tim's original work on the effects system has enabled fgdata developers to do fancy stuff like ALS, I am pretty sure that if a single C++ developer were to integrate these 2-3 features and patches to make this functionality available via the Canvas system, we would end up with a very useful toolbox/playground that could enable non-developers to tinker with alternate scenery/terrain rendering approaches without having to be experienced SG/FG coders, especially if this is coordinated with the ongoing Compositor work - at that point, we'd have all the tools at our disposal to do really cool stuff without having to patch/rebuild SG/FG, which would mean that people familiar with Canvas, Effects, Shaders and Nasal could implement tons of cool functionality without having to go through C++ space.
http://wiki.flightgear.org/Canvas_Devel ... y_Overlays