[sldev] Local textures for fast editing; was: SL 2.0?

Nexii Malthus nexiim at googlemail.com
Tue Jan 19 00:21:24 PST 2010


Fully agree to Stickman here.

Seems like it might be a fairly small challenge to implement, skipping
the upload pipeline and a mechanism to keep/refresh the asset locally.

It doesn't have to be fantastically complicated, the feature would
serve a single purpose. It ought to be able to handle multiple local
textures though, not just a single one, just because it could.

- Nexii

On Tue, Jan 19, 2010 at 1:56 AM, Stickman <stickman at gmail.com> wrote:
>>> http://jira.secondlife.com/browse/VWR-14320
>
>> That JIRA describes quite another thing.  Although it gets around the upload
>> charge, it still requires an upload.  It is still done on the servers.
>
> You make a very good point. Local files would be much faster. That's a
> good advantage to local files. Server files would let other people see
> the changes, which is a different advantage.
>
> Your goal you state is exactly my goal. Make editing simpler and faster.
>
> But in his Jira it says:
> "If it points to a local file, that cuts out the upload time AND the
> download time..."
>
> He points out the existence of "temporary uploads" as existing in
> other clients, then expands on the idea in the same way I did. Like
> me, he doesn't care if it uses local files or these temporary uploads,
> he just wants textures to auto-update while you're building.
>
> That's the whole point: Auto-updating temporary assets (server or
> local, who cares) so you can see your work in progress.
>
> If they were done serverside, I'd handle the "lag" or wait of a round
> trip and love the fact other people could watch. If they were done
> clientside, I'd love the speed of change and deal with the fact other
> people couldn't see me work. I just want the tool.
>
> -Stickman
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>


More information about the SLDev mailing list