Upload.. Bank?

Ok my idea is about uploads, I was thinking about textures at the time, but if it works, it should work for sounds too..

From what I've heard, when you upload textures and sounds, they go into the servers, and stay there, even if there isn't a copy in yours or anyone elses inventory? (correct me if I'm wrong.)

My idea would be, to be able to browse the textures/sounds you have uploaded, and redownload them for no fee (as they won't take up any server space?).

This would help with..

1. Deleting, emptying trash and then thinking.. "Wheres that texture I uploaded a while back?", I know I shouldn't do it, but I do

And

2. Crashing at just the wrong moment? I know I'm definatly charged when this happens, but I don't know if the upload goes through or not. Suppose it depends at which point you crash. Maybe if you crash after being charged but before the upload goes through, it could give you an extra upload or something?

I don't know I'm just throwing ideas about! Would love some imput on the idea. Especially from someone with a better knowledge of how the asset server works.

Thanks!

I totally agree with you. I hate having to take screenshots of my snapshots; it's very hard because taking screenshots lag up the game and end up taking pictures of the background instead of the front of the picture.

You don't need to take screenshots of your snapshots to get them on your HD. Just have the texture or snapshot displayed on screen and go to the file menu on the top left corner of the screen and select "save texture as". It will then save the texture to your HD, providing you have full permissions (copy and mod), if you don't then this option will be grayed out.

One thing to keep in mind though, stay as close to the original as possible if you plan on ever uploading it again. Apparently the file stored on the SL servers is in JPEG format, which when you resave in that format you will loose quality. Once or twice you probably won't see a difference, but more than that and it will start to get blurry. So don't download a texture/snapshot change it reupload, then later download the changed version to alter and reupload again. ALWAYS go back to the changed file on your HD, or redownload the original file from SL, make alterations and reupload. This way you will stay with a second generation JPEG file. The more generations (resaves) the worse the image will look.

-DB

CAVEAT: I don't know what actually happens.

I suppose LL programmers designed the system so that items (textures, sounds, animations, objects, etc.) are automatically discarded if they are not used by anthing in-world and are no longer present in users' inventories.

I should have mentioned this in my previous post, but forgot (oops). With regard to what happens on the asset server, I don't know "exactly". However, I have heard lindens refer to the need for a quicker "clean up of asset server". Now the only way you could "clean" it I believe would be to get rid of unneeded data. Most likely the clean up happens after a file is no longer referenced for a while and they are looking into a method that will speed up this process.

-DB

Actually, a friend told me that when you "save texture as..." it saves it under TGA format. Isn't that very high quality?

It's lossless. However, the process of uploading from an external source into SL will cause some loss of quality because of the internal JPG2000 format used. But saving from JPG2000 to TGA doesn't cause any additional artifacting and whatnot.

ALSO--

I have crashed out several times when uploading various media. Looks to me like you will not get charged until AFTER the asset has successfully been uploaded. So if it happens in the middle, no L$10 gets deducted. Just upload again. If you find otherwise is the case just say so!

I finally had time to put in words my ideas about the asset server's bottleneck problem.

----
Here are a few ideas for asset server's garbage collection. I suppose some or most of them have been already tried and either implemented or found inadequate and trashed. It would be nice to know more about it... I am a curious kitten

1. Low priority scan for unused assets. The grid-wide backups area ideal for this task. Scan the backups and build a list of unused assets, then remove it from the asset servers. It can be done off the main grid, distributed over several machines (it's basically a scan and merge operation, ideal for parallel execution) and it doesn't hit the main grid resources. However, the sim themselves could be used to run these low priority batch scans when they have low load.
   
2. Reference counting. The simplest, count the number of things that reference a given asset. The presence in a user's inventory, in an object's inventory or on its faces (for a texture). Now, SecondLife is a complex beast: thousands of sims working concurrently on the same assets. Doing garbage collection isn't easy and can put additional strain on the poor asset server. There are a few strategies that can help:
   1. Count by the sim. It means we reference count asset usage in the sim and hit the asset server's counter only when the asset start to be used or isn't used anymore in the whole sim. This should reduce the additional load to the bare minimum.
      
   1. Generational garbage collection. Typically, assets will fall into two categories: those being widely distributed and those who score just a few uses if any. These two parts require different strategies: we want to make access to the common things as fast as we can, while we want to clean up as soon as possible the rarely used items when they become not used at all.
      
      
      
      Thus, we can get away not reference counting in real time the widely used assets, relying on the kind of batch garbage collection described in the previous point.
      
   
   
3. We don't need a stinkin' asset server. Do we really need the expensive beast? The assets' UUIDs are an ideal way to partition the data and distribute it around multiple machines using a distributed hash table, I bet its a strategy already used on the current asset server's cluster. Then, why don't we go grid-wide? Putting a little bit of the grid's assets on each sim. Using replication to ensure that even if some of our servers fail – and they do in RL – our data is safe. We can use Google's file system for it. This opens up access to interesting optimizations:
   1. Reduced load on the sim for client-side assets' loads. The viewer could access the server that holds the assets (sounds, textures, etc.) directly, without the current double hops: viewer to sim, sim to asset server, and back.
      
   
   
4. Peer-to-peer sharing of textures/sounds. (Not really a garbage collection method, but it would help dramatically to speed up SL) When you enter a given sim, all of the avatars already there have downloaded the assets. So, why asking the sim for that data if the viewer can ask its peers? Techniques like bubble packets can be used to pass firewalls in a safe way, that's how Skype works. The sim would only be involved in the initial setup of the communication and in certifying that the asset are actually correct and have not be tampered with, by providing a digital signature for each one.
   
5. Better inventory management tools for the users. No one is happy with a huge inventory, however I have more then 13.000 items in my own. Why? Because cleaning it up is a pain, the interface just isn't good enough – it's meant primarily for use and interaction in-world.
   I saw a proposal for an external inventory management application, instead of the full viewer, we'd be presented with an optimized interface to move things around our inventory, create or delete folders, delete items, etc. Please, by all means, implement it or open up the viewer's data structure so we can write such an application ourselves and contribute it to the SL community.
   

[/list]
I'd like to see an inventory management system with a window where the item is displayed as a rotating preview when you click on it in the inventory, instead of having to rez it.

OT:

WHAT!!! IT DOES NOT CURRENTLY USE "reference counting" ???

Right now every time you edit a script or note it gets a new key.

The asset server should be checking the "reference count" and immediately deleting the old item after the save of the new one is complete.
Without "reference counting" each save would add another entry that
would have to be removed during a garbage collection.

"reference counting" is efficient and only requires "Garbage collection" to take care of things that get lost during crashes.

---
I'd also suggest storing peoples assets in the server where there home position is set to and use the asset server for homeless accounts.

No, it does not use reference counting, nor would likely the counts be reliable if it did and I probably need not explain why a zero reference count on a referenced asset would be a Bad Thing.

Thus they'd have to use a mark-and-sweep, and if the LL hints of the size of the database are within a factor of 100 of correct, it could probably be proven that such garbage collection might complete within some finite number of years.

So it goes.