I modified osgEarth such that We can create a image layer and then specify whether the layer should use data from one source or multiple TMS sources. So I can create a layer which fetches tiles for particular region by searching the your TMS cache for tiles of that particular region.
In the above method my algorithm used to fetch the image corresponding to particular tile key and whichever image is found first is used.
Now I have changed such that it finds all the images corresponding to the tilekey and then does composting to get a final image. this composting can be GPU or CPU based depending on users choice.
Sounds useful - it would be interesting to eventually wrap this up into a "CompositeLayer" layer type or something like that - a virtual layer that "stacks" image layer patches much like the elevation subsystem does.
Earlier I was doing compositing in a little crude way but now it has been refined. Also I have somethings with TMS sources.
1. multi TMS support - I an particular Image Layer using a TMS we can add multiple TMS sources as sources to look for for a particular tile request. Suppose I have 10 TMS sources T1,T2,T3 .... ,T10 I create a Image Layer with T1 as TMS source and assign T2,T3... ,T10 as my multiTMS sources. So during the runtime when a Image is requested for some tilekey (x,y) and some zoom level. My algorithm looks for the desired image in T2,T3...,T10 and returns the image which is found first for above tilekey and zoom level. if no Image is found it goes with reqular osgearth approach.
2. In above case suppose number of images for a particular tilekey comes out to be more than 1 (can be greater than 4) my compositing algorithm takes these Images and gives them to a camera thread, which uses a PRE_RENDER camera attached to map node, to combine all the images. the incoming request for composition gets queued in the camera thread and does not stall osgearth workflow.
the pre_render camera combines the images on GPU using fragment shader.
3. I have also implemented an algorithm to composite (or combine) images on the CPU, user can choose between CPU and GPU compositing.
GPU based compositing can combine 32 images (nvidia cards support 32 textures in Pixel Shader) in one pass. if the number of images are more than 32 then it does composition by doing it multipass.
I would like to enhance these features further.
I would be happy to share the code and if it is desired to make it a part of osgearth (please let me know about the programming guidelines etc for this).
I would be thankful if someone can explain a little bit on how does rendering process follows in osgearth. I mean when I get an image (corresponding to a tilekey) where does it get converted into texture , which function does it.
Also how can I add some more xml attributes to .earth file ?
To answer your question: Each terrain tile is an osgEarth::VersionedTile (which inherits from osgTerrain::TerrainTile). Basically you set the TerrainTile::ColorLayer with the new texture image, and it gets applied in EarthTerrainTechnique whenever the tile contents change.
This sounds really handy. I would love to see this sort of GPU-based compositing in osgEarth. Does your work only apply to the TMS driver so far? Does it assume that all the TMS sources you enter will be in the same SRS? It would be nice to elevate this functionality so it could operate on any driver source, and so it could support reprojection as well.
In the meantime-- if you would like to submit something, please do and we'll take a look. And perhaps collaborate on how to apply the technique across all image types. Thanks.
just like the getURL function inside the TMS.cpp I have Implemented a function inside TMS.cpp. So this new function works in almost the same way, it takes in tilekey and zoom level and results the url of image corresponding to it. So as I havent done anything taking into account the SRS so probably I am assuming all TMS will have same SRS.
My work applies to TMS driver only so far. I wish to make this more generalized kind of thing.
Also I had another question on how can I add more attributes to .earth file ? How do I modify .earth file parser so that it can recognize more attributes ?
Map-level attributes are managed in the EarthFile class or in the MapEngineProperties class. Driver-level attributes are handled by each driver.
Each driver has an "options" header-only class (e.g., the osgearth_tms driver has "TMSOptions". You will see that this uses toConfig() and fromConfig() methods to handle the serialization of driver settings. Typically you will want to declare the settings using the optional<> template since it supports default values.
I am sorry I got engaged with something else so I was unable to reply. i would like to submit the code I had written for composting (as mentioned in my previous post). If you would like to add it to osgearth source then you can let me know what all changes are required to be done.
In the meantime learning from what has been done in osgearth_seed application. I made a small application using the code from osgearth_seed to cache tms offline with composting also. So effectively osgearth seed runs and whenever it finds overlapping images in the tms it does compositing to get a composted image for the particular region.
In case of offline composting whenever a request comes for composting comes I create a osgviewer and the composting camera is added to the viewer, viewer renders 1 frame and exits. So this way I see flickering going on when this seed app runs as each time composting is done a viewer is created and destroyed. I was thinking if there is a smarter way around this ?