Can Scripts Automatically Upload Textures?

[TwlightSparkle]

I'm new to LSL Scripting but I was wondering if it was possibly for a script to dynamically upload and create an image/texture. I'm planning on receiving it from an HTTP payload from my own server.

Is it possible? Otherwise I'm going to have host the image to make the user download and create their texture in world.

Edited August 20, 2020 by TwlightSparkle

[Ardy Lay]

Silly answer (This has been done): Sure.  It's a slow process though.  Have it rez full-region pixel art using tinted prims from task inventory.  Wait for the map tile generator to update the map tile for the region, then pull the map tile UUID and use that for whatever you like.

Real answer:  Seems unlikely.  I have poked around the LSL pages in wiki.secondlife.com and don't see a straightforward way for a scripted object in SL to create a texture asset.

I suppose your script could create URIs containing Scalable Vector Graphics and use that as the URL for "media on a prim", but that also seems unlikely to be what you want.

A "scripted agent", aka "bot" could do it but you asked if an LSL script could.

Anybody out there got any better answers?  (Hope.)

[Profaitchikenz Haiku]

6 hours ago, Ardy Lay said:

Have it rez full-region pixel art using tinted prims from task inventory

A slight problem here (although I admit I was impressed with the proposed hack).

A 512 by 512 image needs 262144 pixels. Creating a mesh square tile with 8 forward-facing individual faces would reduce this number to 32768 prims, but region prim-limits are going to bite you in the bum.

 

A 64x64 image could be done this way using 512 prims, which is actually doable in most areas.

 

[Nova Convair]

Short answer: no

You need to upload all textures (10L each) - then your website can distribute the texture UUID to a script and the script can apply the texture by UUID.

A MOAP face can display a texture from a website, but thats not practical for normal building textures and only useful for special cases.

A bot can upload the texture and send the UUID to an inworld script. Your bot requires some money since upload = 10L and it should avoid multiple uploads of the same texture. You need to handle the triangle user-script - website - botscript.

[Whirly Fizzle]

Create a test account.
Write an automated action web script thingy  to upload the desired image to the test accounts web profile image, which is free.
Grab the profile image UUID.
The rest is easy.

Edited August 20, 2020 by Whirly Fizzle

[Qie Niangao]

But will the web interface to profile pictures work forever?

If so, here are a couple links that web scrip thingy might use: https://my.secondlife.com/settings/profile#fl_image and https://my.secondlife.com/settings/profile#sl_image -- that way it can do two images at a time: double the bandwidth!

[TwlightSparkle]

If context is any help, I have a trained super-processing models for types of textures that I'm going to use to provide enhancements for. I have a script right now that the user will provide a texture, pay, and then the texture will sent to my server where it will be processed and sent back to the script in a continuous flow. The issue has been giving the new freshly made texture back to the user handled by the same script (I was planning on expanding it to a fancy kiosk with options).

However, it seems like I'm going to have to make a bot if I want to create and guarantee that the textures given to the customer/user will be no mod and no transfer. Figuring out how to get a bot to listen to my server is a different issue I'll have to figure out (unless I can tie it to fire off locally on the same machine or something).

From the comments, there doesn't seem like a direct way around this. Thank you for all the feedback!

[Kyrah Abattoir]

If it's not fullperm they won't be able to use it properly.

[TwlightSparkle]

19 minutes ago, Kyrah Abattoir said:

If it's not fullperm they won't be able to use it properly.

Sadly that's the drawback. It's a pet project for my own stuff in the meantime. I'd need a more complicated solution to make it work for non full perm textures, probably with appliers linking to my remote service instead of giving them an actual texture.

[Qie Niangao]

I think the question is why one would ever want the textures to be anything other than full perm. But I don't actually understand the use case. I'm not sure if the customers would want textures, as opposed to web hosted images, or texture UUIDs.

[TwlightSparkle]

17 minutes ago, Qie Niangao said:

I think the question is why one would ever want the textures to be anything other than full perm. But I don't actually understand the use case. I'm not sure if the customers would want textures, as opposed to web hosted images, or texture UUIDs.

I think you're right. I forgot that most mesh apply straight through the UUID. It's a lot more user friendly to have it done automatically. I should assume that users don't want to make or configure their own appliers, even if they know how to. I originally wanted to limit permissions because I either might want to limit copy/transferring, or I don't want to be at fault if someone sends me a texture they don't fully own somehow. Just trying to avoid having that is on the rules sort of thing.

[Kyrah Abattoir]

That being said, I'm not entirely convinced that Linden Lab will just "let you" do automated asset creation for very long, depending on volume.