My Open Source Wish List

Now that the SL viewer has finally been open sourced (which was LL's plan from day one), we for the first time have the power to fix all those little annoyances that have been driving us nuts for years. I'd like to take this opportunity therefore to present to you my wish list for what I want the client to be able to do. I invite and challenge the programming community to jump on this, and add these features that we humble artists so desperately need. Who's game?


Chosen's Wish List

1. Duplication Options
   
   In most other 3D modeling applications, when you duplicate an item, you have the option of calling up a dialog that allows you to specify how many copies you want, how you want them spaced, rotated, sized, etc. Making a spiral staircase in Maya, for example, can be done in two clicks. In SL currently, it can take 10-20 minutes, as each piece needs to be placed by hand. Mirroring an object in Maya, even a super complex one, again is a 2-click process, but in SL, it currently takes forever and a day, even with the aid of well scripted tools like Jeffrey Gomez's Prim Mirror.
   
   Duplication options are absolutely the highest priority item on this wish list.
   
   
   
   
2. Inworld Painting Tool
   
   It's so ridiculously time consuming to align textures across complicated, multi-prim items in SL. So much back and forth between Photoshop, a 3D painting tool if you've got one, and SL itself. It can take many hours or even days to texture a complex object properly.
   
   I'd love to see an inworld tool that can allow you to paint directly on prim surfaces. Not only will this speed things up exponentially, but if you think about it, it will actually make the creation process much more balanced. Right now, anyone can create objects, but only certain people can texture them. Not everyone has or wants to learn Photoshop or a comparable raster editor. With an inworld painter, anyone could make textures right away. Of course, better textures will always be made in dedicated programs like Photoshop, but at least rudimentary ones should be allowed to be made directly inworld.
   
   The workflow I have in mind would be you edit a prim, and call up the inworld painting tool, which would have a Photoshop style toolbox on it with all the standard painting tools (brushes, stamps, etc) common to nearly all painting applications, as well as a dialog to choose your texture size, assign a file name, local file location, etc. When you begin to paint, you're actually editing a raster file on your own hard drive. Because it's local, you see can see it in your SL client on the object you're editing, but no one else can yet. Then when you're finished, you click to upload the texture and apply it to your object, and then it's just like any other texture; everyone can see it.
   
   
   
   
3. Dockable/Removable Floater Windows/Toolbars
   
   
   This one's huge. I don't know about anyone else, but absolutely hate how much space all the floater windows take up in my viewer. Lowering the UI size helps, but it's the wrong approach. What I'd like to see is some options for those windows.
   
   Wouldn't it be nice if that editor window didn't block your view of the object you're trying to edit? God, I hate that.
   
   First, you should be able to dock the things, and have them transform from those big honkin' windows to nice, compact toolbars. This is something Microsoft Office got right 10 years ago. It's shameful that SL never has. I'd suggest something akin to Photoshop's interface, where all your options for your currently selected tool are in a nice, neat, out of the way but easily access-ble bar across the top of the screen. Oooh, that would be nice.
   
   Second, you should be able to move the floater windows outside the confines of the SL main viewer window. I refuse to believe it's that hard to set up a GUI to do that. Just about every other program on Earth can do it, but for some reason, not SL.
   
   For those of us running multiple monitors, we should be able to move all the floaters to the secondary screen, out of the way, just like we do with all our palettes in Photoshop.
   
   
   
   
4. Multiple Monitor Support
   
   
   Speaking of multiple monitors, one thing I absolutely hate is how SL's FPS gets crushed when the viewer window spans more than one monitor. It wasn't always this way, but it has been for about two years now. I forget which update it was that killed it, but it used to be you could span two monitors, no problem. Then, all of a sudden, you couldn't. Overlap by as much as a single pixel, and you lose like 75% of your FPS.
   
   I realize not all computers may be experiencing this problem with SL, but the fact is none of them should be. Most other programs don't care whether they're spanning one monitor or a hundred. A desktop is a desktop is a desktop.
   
   
   
   
5. Customizable Menus & Toolbars
   
   
   This one's probably relatively easy. In most programs, you can control what buttons appear where, how menu trees are laid out, etc. It would be really nice to be able to do that in SL.
   
   
   
   
6. Texture Orgainizer
   
   
   Thanks, Ledje Gorky, for pointing this out. I'm not sure if I'd thought about this before, but I know it wasn't on my mind today. It's definitely important.
   
   We need the inventory window to be able to (among other things) display thumbnails of textures. Something like the standard Windows file browser would be ideal, and I'd imagine not too hard to impliment. Something like Adobe Bridge would be even better as long as we're wishing here, but I'd be thrilled with just the file browser.
   
   
   
   
   
7. Projection Handles on Textures
   
   
   Great suggestion from Chip Midnight here. This is something I definitely hadn't thought of, but I love it. We should be able to see a rectangle that represents the projection boundaries of a texture, with handles so we can dynamically scale, rotate, and offset the project, without having to punch numbers in for everything. In other words, place textures on prims the same way we place prims on the world. What a great idea.
   
   
   

Okay, that's my top seven so far. I've got lots more, but that's enough to get started with. Anyone up to the challenge? Please?

I'd like to see the ability to choose your cache location and adjust it to a larger size (that is, if the benefits of more locally cached content aren't offset by the cost of searching the cache).

I would like to add to that :

* BUILT-IN TEXTURE ORGANIZER

Im tired of those crappy prim-based texture organizers. I want a texture organizer in the client that will let me see textures in thumbnail format (up to 20 a page).
Something comparable to XnView.

Well there`s already "avpainter" but I guess that is not for prims. My g/f bought it for me but I can`t get it to run on my computer.











---------------
I would like the horizontal scroll bar brought back when you click to buy an item. That way you can see the full item name and perms.

YES!

we need some type of "browse" feature. It`s a hassle to be double clicking every texture to see what it is.

Good call! Yes, we need a thumbnail viewer. I'll add that to my origninal post.

Probably the top of my list would be better projection mapping of objects. Show me a rectangle that represents the texture that I can move with xyz handles relative to the surface I'm texturing. Instead of tweaking tile and offset values, let me scale and move a mapping gizmo.

I'll second the request for dual-monitor support... even if it's just a secondary window to park all the HUDs and pop-ups and tool boxes.

Keeping the SL 'main view' on one monitor and putting a 'blank' window on the other where all the popups and dialog boxes, tools etc would go, would be lovely! Even having that functionality on a single monitor would be grand - then what you are doing, who are are with, etc would never get covered up when you open the map or the search window etc. etc.

-Atashi

Ooh, good one. Adding this to the OP.

Today, we are all Chosen Groupies

Seriously, thank you for quickly turning a panic into something constructive.

Just today? Damn.

There's a little saying in the open source community about wish lists...

Get to work!

As soon as someone makes the C++ programming knowledge module that I can plug directly into my brain, I'll get right on it.

Rather than add more building tools, I think it would be much wiser to add the ability to upload 3D meshes. This way we can use dedicated modelling applications to make 3D content. Applications that already have all the features mentioned above and more. Prims aren't the way forward.

The prim must go.

The only reasonable argument against 3D meshes is the fact that they're easy to steal. Now that the client is open, that argument is over.

Inventory file manager
a real one
-LW

Inline machine-translation, so folks with the client can understand chat spoken in other languages.

This has already been done with an object, that I assume goes out to babelfish, but its clumsy. Would be nice if we had some sort of machine translation, even limited, built into the client.

I have a couple of good comments for you on this. First, the open source client doesn't and can't affect what you can upload, so we're slightly off topic in that sense.

Second, when I was at SL Views, I did manage to corner one of their graphics guys, and talk about meshes for a little while. It turns out the biggest obstacle with them is not what I'd expected.

It's not the increased amount of streaming data they require, which was what I'd always thought. It's true that meshes are way bigger, data wise, than parametric prims, but the amount of bytes that describe a reasonably sized mesh is not much different than that of a large texture, so it's not a huge deal.

It's also not physics, which I had thought was another major obstacle. It's easy enough to make meshes phantom, and then throw on a few invisible prims to lay out a basic collision lattice. Physics problem solved.

What is the big hrdle then? It's something I had never thought about, LOD. How the hell do you assign levels of detail in the renderer to an arbitrary mesh? The levels of detail that you see for all prims, land, tress, avatars, etc. are predefined values which your client already knows how to draw. For user-created meshes, that data wouldn't exist. So what do you do? That's a huge stumbling block to overcome. Once somebody figures that out, we'll be up to our ears in meshes, but until then, it ain't gonna happen.

Console client:
The linux client should be easily modified to run on Linux PS3
A managed DirectX port might enable Xbox360 support someday
anybody feels like cyber with a wiimote yet?? (i have no idea how *open* to homebrew the wii is)


Windows Client:
he disadvantages of using glide without a decent game engine are dripping from the client. what i mean to say, the ingame UI looks like a game from '98.
a managed DirectX client can really lower the entry barriers for programmers & integrates with windows like a charm

MAC/Linux client:
There's got to be a game engine out there that makes more things possible


disclaimer: I love managed DirectX

from Resident Answers to Feature Suggestions.

while i'm aware of the importance of this issue and the relevance to the community, this thread is a discussion of features and really doesn't belong in RA.

perhaps we should be requesting a new forum for threads that deal specifically with the Open Sourced viewer? i'm sure there will be plenty of requests, questions, ideas, etc. that could benefit the community by all being in one concise forum.


but, oddly enough, i have a question.. will this open sourcing be able to be used to make changes to the building tools? such as new prim types or new prim editing tools?




Edit: sorry.. i meant to leave a re-direct in RA.

A mesh doesn't NEED different LOD. It's just something that helps performance. Also, the renderer doesn't have to draw meshes that are far away in the distance.

LOD could be optional. If the upload contains versions of the model with reduced detail then the renderer will use them. If not, the renderer simply doesn't draw the model when in the distance.

If you're worried about rendering performance then prims definitely must go. Think about how many polygons are wasted in a detailed prim model. Take just two intersecting spheres for example. The hidden and intersecting polygons on the surface of each sphere are still drawn by the rendering engine. This means that 50 percent of the polygons have gone to waste. Prims are far from efficient.


Burn the prim!

Make the cone of context able to be turned completely off.

Allow removal of IM chat from the scrolling up the screen chat display - so you can see just the local public chat without using the chat history.

Allow adjustment of text size and color in different parts of the interface independently.

As already mentioned, a sleek slender toolbar, like Corel uses.

Ability to move interface elements around.

Text to Speech, ability to assign different voices to different avatars. Should be able to use good quality voices like NeoSpeech Kate.

Ability to create a text file with all debug settins and the comments.

Ability to save all scripts in a folder to text files.

Abilty to use script editor of choice - or at least to turn off the indentation.

Allow rightclicking a word in a script and doing an LSL wiki lookup.

Allow use of the sl mozilla browser instead of system default browser.

Identify the creator of objects that send chat and IM.

Allow setting colors of interface elements so the viewer is not butt ugly and hard to read.

Allow storage of several email addresses to select from in the snapshot email dialog. I am so tired of typing [email]pics@slpics.com[/email].

Treat dialog boxes and such as if they are physical layers and allow one to move the up and down in the stack. Don't render the underlying areas of overlapped interface elements. Purpose: to have overlapping transparent interface elements which don't show the layers underneath, so you can have a bunch of dialog boxes overlapping, and when you click on one, it comes to the top of the stack, and is displayed without the underlying interface elements making it hard to read. When done using it, a keystroke or mouseclick would make it go back to it's previous level in the stack of interface elements. This would mean you could have a bunch of transparent interface elements, some overlapping each other, but only one cumulative layer of interface obscuring the world display at any given point. I find this challenging to put in words.



Abilty to turn off the graphs in the stats display, so they never show back up again till you turn them back on.

Make all the debug settings that possibly can take effect immediately do so instead of requiring restarting the program.

Go ask in Resident Answers!

Nobody is going to see your stupid question here! You pig!!!

STFU!




Sorry, that was babelfish talking.


What I meant to say was - "Great idea, Travis! "

lol.. great point!
(and i appreciate your sense of humor.. it's close to my counter-parts, The Quirk)

but i digress.. sorry for the off topic post guys.

Caching is my major new feature. It could be as simple as a cache-per-sim. Each simulator you visit gets its own cache folder (up to whatever limit we have atm, 1gb I think) and the user simply specifies how many of these to keep, when that limit is hit, the simulator least recently visited has its folder removed.
This can then be expanded so that each simulator's cache can hold more content and more intelligently, but it's a simple system that would make a difference fairly easily.