My Open Source Wish List

Allow copying and pasting of text anywhere possible in the interface, including copying the names of groups, the names of people in group lists, error messages, text displayed in group notices, etc.

Allowing giving people items by clicking on their name in places like IM tabs, the friends list, etc. without having to pull up their profile.

Hours running SL display - this session, cumulative, etc.

Allow eliminating pie menu animated effects crap and using a non-gestural pie menu.

Add an Always Snap mode so you can snap a thousand things in a row without having to slide over to the rulers.

Add menu item that allows one to snap x, snap y, snap z, or any combination of the above.

Allow savings of all settings as a group with a name.

Make an undo stack for settings - so that if you for example change your script editor font size, you can just select undo from the settings menu and it puts it back like it was.

Undo for your appearance, attachments, etc. so if you put on some shoes and they look rotten you can just undo and the nice looking pair you had on reappear.

ALT MANAGER!!!!

Put the draw distance selector on the screen where you can see and use it without having to go through a dialog box.

Allow several different sets of settings for different conditions to be saved and have the selector for that be able to be onscreen all the time

Allow us to change the "PST" to "SLT" the way it ought to be!

Location bookmarking - records locations teleported to so you can Un-Teleport and go back where you where.

A GoTo field with "intelligent" parsing that can handle a number of different ways to express a sim name and a coordinate such as "Ahern 12, 23, 56", slurls, secondlife://simname/x/y/z; "Ahern (12, 24, 60)" etc.

Menu option for injecting C++ knowledge directly into Chip Midnight's brain.

Well I dunno about getting SL running on a Wii, but it certainly seems like it would be possible to get a Wiimote to control SL on a PC if this is anything to go by.... http://spazout.com/roomba/

This wouldnt help with HUDs, but how about an option to drag SL floater windows out of the SL frame completely so they're just regular OS level windows, and you can put them in any screen. They wouldn't be OpenGL objects any more once this was done, so you would automatically avoid all the OpenGL spamnning problems.

That's not something the open source client can do anything about. Creating a "mesh" object you couldn't upload into the world because the sims don't know what it is would be pointless.

This would be *easy* to implement based on a hook that I have long wanted: the ability to direct chat to a socket or stream and back again, so you could simply have an external program listening to your chat onput and output and filtering it, in both directions.

That would make it possible to implement all kinds of extensions as simple scripts in any language and you wouldn't have to upload anything to Chip Midnight's brain.

Or vice versa.

I only wonder 2 things:
How would I get the O.S. customizations I want and not others?
And, how would one keep one's customizations when LL releases a new client?

There are a variety of ways to do this. Conditional compilation, command line flags, or optional libraries.
You would keep using the old client, with a mod that lies about its version to the sim, until the changes were available for the new client.

SL client viewer within Firefox.... guess that would be a Firefox extension. That way you could get a 3D scene of a SL location within Firefox... awesome!

I've mentioned this elsewhere but I suppose I can stand to say it twice

Extend the client with a client-side plug-in scripting language, such as LUA. Limit the interface with this scripting language so plug-ins can't steal your password, your inventory, your L$, etc. Then, make the client-side scripts objects on the asset server (I know we can't change the server but LL might be prepared to do this).

So, if you want a better texture organiser.. you don't just hope that someone implements one in the version of the client you're using. You go to a shop in-world, buy one, and recieve a "plugin" object in your SL inventory. You open your "SL plugin manager" window, drop the "plugin" object from your inventory into it; SL downloads the script to be run client-side and merges it with your client, and up pops your organiser as a tab on your inventory window. And you know you can trust it, because the plugin interface won't let it do anything untrustworthy.

As for other things, a context-based UI would be nice. I'm thinking of something like Microsoft's Ribbons, but they apparantly have some weird licensing attached to them now, so that probably isn't an option. "Build" for example, wouldn't just be a button on the bottom bar anymore; it'd be a tab, which would give you a completely new button bar with building specific commands.

Oh, and please, please, someone.. make it so that when building, the selected object(s)'s axis rose is always within the view frustrum even if the centre of the object isn't. Please?

Excellent suggestions, Chosen! Suzanne, yours too.

Argent, there is a free translator HUD which is great. Search for "babble", or IM me ingame.

Client-side scripting is an interesting idea, especially for worn objects, which could do things that your avatar can do (like talk, move, look, etc.) Goodness only knows what clever innovations folks would come up with using this kind of thing!

And it could be useful for building things programmatically, for the technically minded. I wonder what restrictions there would be on the kinds of events that the client could detect and provide to the client-side scripts.

Client-side scripting has been thought about. It is a very good idea. Being able to install scripts directly from SL Inventory would be key. Most of the UI can be scripted. I was thinking of ways to edit such client-side scripts... =)

I'd like to see a client that can be run multiple instances on the same system. I wouldn't do this very often, but for special purposes it can be useful.

I would use it for testing scripts where the functionality changes after a purchase, stuff like that. I'm sure there are plenty of other valid uses. As well as a few weird ones, but there's nothing strange about weird in SL.

Prims are actually very efficient to calculate and draw, LL's just chosen to make them more complicated than necessary to make them look good when lit. You can change the client to use the appropriate amount of polys per prim (like 12 for a cube of any size), but the lighting system would need to be changed from vertex shading to pixel shading. Ultimately, pixel shading would look nicer, BUT it requires a better video card, raising the minimum requirements and cutting off a lot of people who just now are barely connecting to SL (ignoring the fact that an old video card with pixel shader support is like... $10 on eBay (excluding shipping costs)).

LoD calculations on a mesh can be figured out dynamically, but it's difficult. What vertices do you drop? And what if the one you drop on one mesh that looks right makes another mesh look wrong? Also, what would the maximum mesh complexity be for uploads? What happens if someone uploads a 30k poly avatar? What would the maximum poly count be? What about the maximum mesh size (no 256x256x256 cube-atars!)? Also, at what points should you reduce a mesh, and would you reduce a mesh that's only 400 polys versus the 30k monster? What rates do the reductions occur at? etc. These, I suspect, are the problems LL has with allowing uploading meshes. FORCING people who upload meshes to upload lower quality meshs for LoD replacement would be a good answer to solve the above, but then you're storing redundant data on the server and space usage goes through the roof.


The above problem is exactly why prims are used. You can calculate how many faces you want for whatever distance and draw them. A sphere is a sphere as long as it looks round, and at 100m who can tell the difference between a 32 segment sphere and a 4 segment sphere (segments being the horizontal sections across the sphere's silhouette). It's easy to calculate a sphere of any amount of segments, and you're creating those vertices you need on the fly. And all you need is the position and the radii (x, y, and z sizes) to make them.

But they're not very efficient for complex models. If you only want to make things like soccer balls and doughnuts then prims are very efficient.

You can do this already, I think - run SecondLife.exe with the "-multiple" parameter.

Actually they can be used to make complex models with CSG. The resultant object mesh could be calculated locally and saved as a temporary mesh. And because it's just prims subtracting or joining with other prims, LoD can be just as easily calculated for multiple levels of detail in seperate meshes.

Addendum:
Examples as listed

1. Automated model building based on aerial photos (pdf)
   
2. Automated curved surface measuring, recreated with CSG (pdf)
   
3. A POV-Ray example of how CSG works
   

The crux of CSG is that it's ideal for building inorganic structures (like houses, cars, bridges, vendors... You know, pretty much everything everyone dwells in or sits on to interact with others). However one of CSG's functions (union) would allow prims to be combined together, eliminating those hidden surfaces in walls, floors, heads, etc. and freeing up a ton of polys.

Yes, I'm aware of CSG.

I don't think you're seeing the big picture though. Prims are crap and Second Life's build tools are crap. So rather than try to improve them, it would be much wiser (even simpler) to allow people to use their own build tools like Blender and create models that don't look like they've been made from a bunch of primitives stuck together.

Also, to the people that say meshes can't be handled client side only. I disagree. It would be possible to store the meshes on our own servers and have the client download them from there. No more asset server problems. WOOT!

Yeah yeah. I know. We wont be able to sell our models using the traditional L$ route. But is that such a bad thing?

Thanks, but it's Travis Lambert who was asking about that.

Prims AREN'T crap though, storage wise and memory wise they are superior to a raw mesh with thousands of vertices. You can make a very complex looking building or vehicle with just prims, and it looks great. Go to Samurai Island and look at the swords there. Tell me they look horrible. They could look BETTER, yes, but that's true if we had CSG at our disposal just as much as if we had the ability to upload meshes (which would likely be a product of heavy CSG usage anyways!). Now if you wanted to model organic stuff (like a face, human or furry) then you've got a problem and I totally agree that CSG is crap. But then you get into things like metaballs for organic structures. CSG + Metaballs = advanced 3d.

Having used 3DS 8 and 9 (I've got 3DS 9 here at home), I can tell you how often I've thought that SL's controls are comfortable while using 3DS to move mannequins about for animation, or building environments. Dedicated modeling programs are rife with other extras though, things like cloth dynamics and hair/fur maps. For the controls that exist in both though, I'm far happier with SL's. They're faster (for me) and easy to use. And primarily, THAT is the key. Ease of use. If EVERYONE can't do it (or at least stumble along with others and figure it out quickly) then it's no good for SL.

I totally agree, I believe SL should shift the assets to the players and let us maintain our own inventories, a sort of peer to peer network as it were. In a perfect world this would be THE ideal solution (*assuming you mean only stuff you wear or rez from inventory. In world buildings and such would still be the domain of asset servers). There would usually be no asset issues, your stuff wouldn't be in trouble of being lost (lest the rest of your drive suffer the same fate, i.e. hardware failure), and everyone sees your updated textures as soon as you change them.

However, many people have a slower upload rate than they have download rates. When you get 12 people all wanting your 1024x1024 upper and lower body, head, and eye blink textures (furries), not counting all the other little textures, you're looking at a pretty narrow tube to shove a lot of data through. Rezzing would take forever for some people, and you run the risk of being dropped from SL due to a lack of outbound packets (what with you transfering files to everyone else). If you're only uploading your files to the server once, to offload to everyone else, how's that different than the current asset server issue? The sim still has the same load issue, except now the data takes even longer to be uploaded from you across the net to the sim, instead of a local server (or at least one connected along a backbone, an "almost as good as" local connection). If you mean to load EVERYTHING that's yours off of your computer, buildings and such in world already included, all of your content is essentially broken while you're offline, or your computer must stay online 24/7 (see * above).

And you're right, it would kill the economy. If anyone bought your stuff, it would be stored on their computer. Remember copybot? The issue there was that people could download whatever they see in world to their computer and upload it under their name. Sounds like the same issue. Only this time, people can buy your scripts as well and upload those too.

We'll just have to disagree on the worth of the prim. Although I do agree with your points on them taking little memory and being easy for new users to deal with. Yet when you've been in SL for a while, they can become very limiting and the limitations of the build tools become very frustrating. Maybe you'll see things differently this time next year?




?

The sim doesn't receive the mesh data. The clients download the data from a dedicated web server which will only have to deal with requests from the clients that view your models. The asset server is currently overloaded because it's having to deal with 1000s of requests.

That doesn't seem very wise since that would force the bandwidth of so many textures rezzing at once.

...unless it's possible to stop texture rezzing any further than 1st level of detail.

I use 3DS 9 at school, I know exactly how limiting SL's interface is. That said, you can still make a lot with just prims, and some of the stuff I've made in 3DS can only be made with CSG. Hence my requests, the research for tutorials, the link in my signature, and my overall zeal in regards to it.

And YES, arbitrary meshes would be awesome too, making an avatar myself instead of relying on the human model (which does a fair job for a human, but what about us furries who want digitigrade legs? Or the giant robots? Or...). I won't argue that meshes would be good, because I totally agree. They would. But, prims are not crap.



The problem with outside servers is that you have to deal with it being down when SL isn't. What happens if your models get referenced so much that the host of said server decides to bill you extra or stop your bandwidth usage because of all the requests? Or perhaps a panic about a DoS attack with the sudden influx of requests (ok, so that one's a stretch, but you never know). If LL could afford another asset server, they would have done so by now (or have, but it's not helping for some reason).

As well, as soon as the flood gates are opened on arbitrary meshes, EVERYONE will do it. Even the people who know nothing about modeling will grab some kind of free program and put something together to try ("look what I made!" "it's.... spikey." "I know!". Bandwidth usage will go way up.


Right, don't know what I was thinking there. But textures would be an asset issue still.