I pushed the changes that allow clients to request textures in all sorts
of mime types. You can do it both with an extra query parameter or with
the Accept header, although I haven't tested the Accept header route
yet. But the extra parameter is working and it's really easy to test. To
test on a web browser do this:
Boot up a sim. Login with the SL viewer. Notice the debug messages
related to the GetTexture cap, like this:
18:45:52 - [GETTEXTURE]: /CAPS/4f56a644-e8ca-4218-bbfc-f4a2eb91facf in
region Kali Test
While you're logged in, pull up a web browser and point it to
http://<wherever>/CAPS/4f56a644-e8ca-4218-bbfc-f4a2eb91facf/?texture_id=<some
valid texture uuid>&format=png
You can grab texture ids from debug messages too.
Voila!
I'm doing the conversion exactly like the MapModule does it. I'm not
entirely knowledgeable of all the options for these conversions, so if
someone has better suggestions, let me know.
On 12/8/2010 11:51 AM, Melanie wrote:
Then no applicable header (like text/plain is not applicable but
could be present!) and no explicit one should be j2c still
Melanie
Diva Canto wrote:
OK, thanks for the arguments on both options -- they're both valid. I'll
do both, with the query parameter being dominant over the Accept header.
On 12/8/2010 11:10 AM, dz wrote:
Aloha,
I thought the whole rationale behind the jp2 processing was that it
was the only library that promised "progressive" texture quality. The
claimed advantage was that viewers would have "something" to display
after an initial pass at the round robin of asset downloads. As
additional packets arrived, the quality of the texture would improve
for those observing it. I don't have the working experience to know
if that benefit was ever realized, and I seem to recall some
contentious posts in the viewer lists doubting it ever would.
In the case where users see no benefit to using jp2, and have existing
catalogs of textures in other formats, I also prefer the solution
described by (option A)... an extra parameter the user can specify,
with a default of the current jp2. I think Melanies point that
Accept headers sometimes can't be set or relied upon, combined with
the easier to debug EXPLICIT type declaration, make (A) the proper
design decision.
D
On Wed, Dec 8, 2010 at 9:09 AM, Diva Canto<[email protected]
<mailto:[email protected]>> wrote:
Then have your client do that. This doesn't affect the ability for
clients to do that in any way: simply omit the extra information.
Other clients benefit from the server doing the conversion, and
the result of that conversion being cached on the server side, so
that future requests get exactly what they need.
Technically, this conversion does not belong to the simulator; it
belongs to the GetTexture service associated with the simulator;
this service can execute anywhere.
_______________________________________________
Opensim-dev mailing list
[email protected]<mailto:[email protected]>
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
------------------------------------------------------------------------
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
