I have spent some time over the last couple months working on the entire maptile system, from generation of region tiles, to robust generation of zoomlevels required for the map itself.
Through that I noticed quite a number of things, but primarily that we still create and store a copy of the region tile to the asset server as "terrainImage_". Searching around the parts that utilize said asset I could only find one part about sending the uuid of the asset to the viewer as part of the RegionSettings. Given the ultimate request for the image is done via the region asset connector anyways, we could just store the image locally in memory and supply it when the requested asset uuid matches. Adding a check in the region asset connector that if no other match returns from the actual asset server(or cache), the requested uuid is checked if it matches a stored region tile uuid. Storing the image data on RegionSettings and simply supplying that as "new" asset whenever a request is made to the region asset connector. Making sure to cache the request as well should it match as that's the first thing the connector looks for. The result is a bit more memory usage for storing the tile at runtime and a faster response in getting the tile asset data. No longer storing the image as an asset removes that spam vector from the asset server, which also removes the need for manually cleaning the database entries and or files out of it as robust does not do this on its own. I asked a while ago whether we even still need that tile data, but apparently there are still viewers that use it over directly requesting the tiles from robust based on region coordinates. I suspect this is because of var regions in some way, although using the tiles from robust and merging them in the viewer, which has a gpu available for doing image processing, would be a better use of resources than having a cpu do it on the server end. I did consider using that already existing option to provide the image, but I think the tile required is of the entire region as one image so it would require merging var region tiles into one image and potentially scaling them, which is a lot more processing than just storing the image and matching a uuid. Also considered giving robust some more braincells in cleaning up the mess this currently creates, but this would require making assumptions about what data to keep or storing even more information about each tile in order to figure out which ones are no longer required. I'm looking for some input on this idea. Are there potential issues I missed? Should the tile be stored as file rather than in memory? Should the V1 tile just be removed entirely and viewers fix it on their end? As mentioned, this is part of a larger project to overhaul the maptile system on both ends. Removing the spam vectors, reducing processing time and increasing the stability and accuracy of the system itself. Eventually, once testing concludes, this code will go up on mantis for comments and hopefully integration. So far it has been working quite well and especially in regards to the zoomlevel generation being a lot more accurate than before. There are quite a few areas that are currently far more rigid and slow than they really need to be, but that's a topic for another time. Regards, Vincent Sylvester _______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
