Hi,
the reason the tiles need to be assets as well as stored in the v2 map system is that both in world LSL scripts and existing 3rd party websites that display grid maps would break. The system is already allowing old maptiles on the asset server to be removed, so they don't build up over time. Of course the "asset" request that is generated by setting a region image asset ID to a prim could be short-circuited locally, and an interface for retrieving map images from some central repository could be agreed between grid operators, but is it worth it? After all, one requirement for displaying a world map is that the tile still be displayable even if the region is crashed, so directly querying the region in question is not an option, also, that would make the world map too slow to be usable on the website. The path of least resistance is to let these sleeping dogs lie, I hope I have been able to shed some light on the asset mystery. PS: OSGrid's map also uses this system of retrieval. - Melanie ---- On Sun, 01 Oct 2023 13:35:50 +0100 Zetamex Network <cont...@zetamex.com> wrote --- 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 mailto:Opensim-dev@opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev@opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
