[sldev] [ogpx] Snowglobe on OpenSim grids

[Dahlia Trimble]

I was under the (possibly false) impression that the SL viewer used JPEG2000
discard levels as a means of mipmapping, at least for textures. The current
OpenSim map tiles used with the traditional map feature are standard image
assets, which should be encoded using JPEG2000. Is the Snowglobe map using
JPEG2000 images as well? If so, what is the MIME type used for HTTP
transfer? I had heard that standard Jpeg encoding and HTTP was used.

Is there documentation available for the map tile protocol used with
Snowglobe?

On Sun, Dec 13, 2009 at 11:37 PM, Philippe (Merov) Bossut <
merov at lindenlab.com> wrote:

> Hi,
>
> On Sun, Dec 13, 2009 at 10:53 AM, Joshua Bell <josh at lindenlab.com> wrote:
>
>> On Thu, Dec 10, 2009 at 10:55 PM, Dzonatas Sol <dzonatas at gmail.com>wrote:
>>
>>> Wouldn't it be better if the map was a LLMediaPlugin. That way each map
>>> window can be customized to a grid. That would also mean each grid would
>>> load it's own viewer plugin.
>>>
>>
>> I would take this one step further:
>>
>> The map is a service provided by a grid, or region-domain in VWRAP
>> parlance. It should have no dependency on the agent domain. It serves to
>> consume and produce location identifiers into the grid which - should be
>> URLs, e.g. "given a friend's SLurl, show it on the map", "generate a SLurl
>> for a location so I can initiate a teleport to it".
>>
>> I would posit that this could be implemented entirely as a web page hosted
>> via a generic web context provider in a viewer - no need for a specific
>> plugin. The region domain would provide a standardized cap which is actually
>> a web page a la slurl.com, which generates URLs the viewer can act on
>> (e.g. to initiate teleport).
>>
>
> Right, when we redesigned the map, we thought about actually using the
> slurl.com web page right there and render it with the internal browser. It
> seemed smart and all but there are data that currently cannot be accessed by
> the webapp, most importantly, the "green dots" (residents location) so we
> fell back to hacking the C++ code. Eventually though, we should think about
> having better webapps and use them in the viewer for this kind of features
> (as we do for some aspect of Search for instance). There's no reason to code
> 2 maps really, not to mention that getting all those rich infos browsable
> from a webapp would be great...
>
> Anyway, in the meantime, a "cap" to get the correct map that corresponds to
> the grid the resident is on seems like a good idea.
>
> That being said,about the current problem of OpenSim, the thing is that the
> new map is using a mipmap structure (subres tiles computed by stitching
> region tiles server side once a day) that allows fast zoom (like in the
> webapp actually, same data and similar method of mapping). Is OpenSim
> planning to do something similar or will it stick with the slow "one tile
> per region" solution? (which is very slow in zoomed out situations). Note: I
> think it's possible to modify the current mipmap and degrade it to use one
> single level of res, avoiding reimplementing the whole old map code which
> has been completely taken out.
>
> Cheers,
> - Merov
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091213/3eeda56b/attachment-0001.htm