Note: Shut down SL before changing these or they will reset when SL exits. These changes will also be wiped each time SL is updated so make a backup of the changed affected files to copy over.
uploads: SL allows uploads of images/textures, sounds, and BVH animation. It would be better if SL also supported ZIPped WAVs, like Active Worlds does, which can retain seamless looping (which tends to get broken when WAVs are compressed into MP3/OGG format (which SL uses the latter of). SL already supports compressed JPG/TGA uploading so images aren't really an issue, though it would be nice to have masked textures optionally separate, also like Active Worlds, so they can be applied to ANY texture:
increases usability without having to manually add a mask to EVERY image in an external image editor
saves bandwidth from having to upload another image with a different mask each time
It's just about being efficient and not being unnecessarily wasteful.
open-source:
LL has discussed how and whether a free software or an open-source transition for SL would be possible, and many LL employees are ultimately in favor of it, while some are skeptical. In any case, there is a bit of work necessary to do before such a move, and we've all agreed that now is not quite the time to throw a lot of effort into it. Yet at the same time many of us (including myself) believe that SL will indeed be dwarfed eventually by an free/open metaverse if LL does not go that route.
The main obstacle in my mind is the protocol that SL currently uses. It has evolved into something unlike what we originally thought it would, and now has obvious shortcomings that we are scheming on fixing. I'm afraid that if we were to open it all up now it would snowball into an unmanigable mess like the open Netscape project before it was scrapped and reborn as Mozilla. The only way I think Free/OpenSL would work would be if LL were to clean up and stabilize the protocol so that it was easily extensible, then release a sample client implementation, and eventually the servers (which really aren't ready for a sparsely distributed system yet).
An open, distributed, shared network was part of the plan from the very beginning when Philip was telling me about it over lunch that first week I came down to San Francisco, and as far as my opinions sway it is still part of the plan.
My recommendation: stick around and see what happens -- it might be interesting.
Incidentally, the back end of SL is becoming increasingly dependent on free or open-source (FOSS) software. Each simulator node now runs a squid, uses libcurl, and a few other FOSS components. It is possible that future nodes will be running MONO and jabber as well. It would seem a shame (it seems to me) to not contribute something back to the whole happy wonderful world of FOSS, preferably FS. (Andrew Linden, 4/6/05)
I'll speak for my own gut here, allowing that I'm sure this will be a long and interesting discussion in the years to come:
My intuition is that open source and open standards are the only way to go for SL long term - for us to reach the whole world in the way that the web has will probably only happen under this sort of model.
I don't think becoming more open would be a bad business move for LL, because there are so many central services that we can offer for a fair price - once SL goes to truly global scale those charges can create a very large and sustaining business.
Pragmatically, there are things that need to happen to make this possible:
We have to preserve some sort of system to protect the rights and permissions of content. This means that in some manner the servers must become untrusted - a 'man-in-the-middle' from a crypto perspective. Today, the SL servers are totally trusted - if you owned a server you could take all the money and copy all the objects of anyone who walked into it. I can imagine that long term you get a notice on entering insecure servers, and you can choose what objects and how much money you want to 'carry' when you go in. Coding this is going to be a big change, and lots of work.
Additionally, as also discussed here, we need to make the protocols between servers very simple, so that folks can start from scratch with server code if they like. HTTP got really widespread in part because it was really simple - you could write a basic server in a few hours. Ideally something like SL needs to be comparably simple - you should be able to write a 'hello world' server and connect it to the grid very easily.
Projects like OSMP are great, and something that helps us understand what priority we should give to these changes. Ideally I'd like to see the metaverse get built as quickly as possible, which means that everyone is working on interoperable code and content. If big projects get underway that are challenging SL in scale and capability, it means that we are doing something wrong - not being open enough fast enough. (Philip Linden, 4/6/05)
If LL ever releases portions of SL as FOSS, then SL will be an even more exciting and interesting platform than it is currently. I think that such a move is likely to happen, but not today.
I think one of the things Philip was saying in regard to OSMP and VU was:
"If a FOSS metaverse approaches SL's feature set before SL goes FOSS then LL loses the race." (Andrew Linden, 4/7/05)
OpenCroquet is an interesting open-source project. It is an ambitious system and by design has more flexibility than SL. Nevertheless, the existence of OpenCroquet does not relegate SL for the history books just yet. Both SL and OC are largely experimental in the sense that they are not feature complete, are only beginning to show their potential, and may very well be fundamentally non-optimal for whatever a final metaverse might look like.
I may have misinterpreted Philip's statements in my rewording since I made my version seem a bit more prophetic and sudden. In the long term the future of persistent virtual worlds is bright. If SL ultimately fades from view it will only be because whatever replaced it was much better -- whatever it is, I think it will be FOSS which is why I think LL should ultimately move SL in that direction if we want SL to remain a contender. (Andrew Linden, 4/7/05)
abuse/griefing
PvP abuse report log needs time/date/location (discuss): The PvP (player vs. player) abuse report log (Help > View PvP Abuse...) just lists the person and abuse action ("bumped with a script", "hit you with their avatar", etc) but doesn't give the date/time/location of the abuse, making it annoying to figure out what happened if there are even more than 1 of the same abuse. Sure, one can report each abuse to find the date/time/location of the abuse but that is annoying.
suspension/banning: When someone is suspended/banned from SL, they can just get right back in with an alternate account (alt). SL should suspend/ban by IP address and even network card MAC address. While still not foolproof, it will make it harder for some griefers to get back in right away at least. Storing a special registry key and/or a file somewhere on the griefer's computer (that isn't easily detectable) to indicate they have been suspended/banned would help, too.
We are at this very moment working on a complete replacement for local lighting. It will be in one of the next few releases, so all I can suggest is to disable it for now and wait for something better that we can actually make fast. I know it is frustrating, but if we spend all of our time supporting broken features (and for a variety of reasons the existing local lighting model is very broken) we will never have time to implement new, better features. (Steve Linden, 3/21/06)
We have in the works a more advanced materials system that will give users control over specular properties (i.e. allow a material to reflect light other than its base color, so a red texture could appear white when close to a white light). I hope to have it out some time this summer, but no promises, we have a lot on the schedule right now. (Steve Linden, 3/29/6)
There are in the current test 4 settings for light: sun and moon only, HW lights only, HW + Software lights, HW + SW + Shadows. I do not know that all settings will be supported by all cards or computers. Both SW options can have heavy performance hits. In HW only, the closest X (I believe it is 6) lights are rendered in hardware. All other lights are only shown as full bright and do not light anything around them. (Kelly Linden, 4/4/06)
In HW + SW, the closest X (again, 6 I think) lights are rendered in hardware, just like the HW option. Lights further away will use a software mode to render and light the objects around them. If there are only a few lights within view, then performance for HW + SW should be very close. Shadows are done in software, I think (hedging my bets here, sorry), and therefore may only make sense as an option if you are already doing some lighting in software (SW). (Kelly Linden, 4/4/06)
Lights will be something completely new. Each prim will have the option to be a light which will enable a set of light properties. If you make all 6 prims in a link set a light, then yes it will use all 6 lights. As for jewelry - ALL existing light objects will become 'full bright' and will no longer be lights. Additionally the color and range (and fall off and cut off) of light emitted from a Light is no longer related to the actual size, shape or color of the Light object. These will all be completely seperate settings. It will be possible to set exactly how far the light from a Light will reach, for example, rather than being determined as a function of the size of the light object. The max range for light to reach will be 20m - no more 10mx10m pink wall turning your whole plot pink. (Kelly Linden, 4/5/06)
There are no immediate plans to include spot lights or other types of lights because they are still expensive to calculate for a large percentage of our users' hardware. We may add them in the distant future, but for now the best way to approximate a spot light is to create a translucent cone linked with a tiny light (but with a light radius matching that of the cone), centered partway between the base and the end of the cone. I'm not familiar with what a "barndoor" light rig is, but area lights can be approximated with several small point lights. (Steve Linden, 4/20/06)
Regarding a framerate threshold for when LOD kicks in:
Steve Linden, 6/12/06, 21:19 via IM: You get terrible feedback loops that way. As soon as you use framerate to adjust computations that can be expensive (like changing LOD), that affects the framerate, which triggers other computations... it can be done but it gets very complicated quickly.
sky (discuss): SL's sky, while nice, could use some improvement. The sun jumps across the sky every 10 seconds instead of smoothly panning (which could be interpolated client-side). The simulator's light source flickers every few seconds during sunrise/sunset. The twinkling stars are nice but SL could learn a lot from Morrowind/Oblivion's sky (and Gothic's with its occassional shooting stars).
Yeah, the silly sun and moon reflections really poke me in the eye every time I see them. I think the plan was to make them twinkle like you see on real water that has texture, which would result in an effectively elongated shape similar to the way they are depicted now.
A more correct night sky would be nice. I think we decided to not make it too flashy in an effort to help keep the render FPS as high as possible, figuiring that the non-moving stars wouldn't bother too many people. There is much to the night/day cycle that is unrealistic. (Andrew Linden, 5/5/05)
mouse control customization: While keyboard camera controls can be customizable, mouse camera controls (or any controls) cannot. For example, to focus the camera on something, the alt+left-click. Zooming in/out requires holding left-click while moving the mouse up/down, but rotating the camera requires holding ctrl and moving the mouse around. Most PC mice have more than one button so they should be configrable too. More intuitive mouse camera control would be to use the right mouse button for rotation (once the camera is focused on something, of course)--and hold down both left and right mouse buttons to pan the camera.
FOV annoyances: The camera's FOV (field-of-view) changes when the camera zooms in on a prim/object close enough. While this can make editing easier at times, it should be optional since, on rotating objects, the camera can change FOV so much it's disorienting. Also, using the zoom in/out View menu options (which just change camera FOV), there is a bug: pressing ctrl+8 7 times to zoom the FOV out freezes the 3D viewport pane. There's also an issue with the keyboard repeat with the FOV zoom/reset keys not always working but I can't reproduce it.
full-GUI 1st-person view: Mouselook (SL's current 1st-person view mode) hides most of the GUI and only allows clicking objects to activate "touch" events. SL should have a proper, full-GUI 1st-person view where everything (object selection/editing, inventory management, IMs, etc) can be done like in 3rd-person view. This can be somewhat simulated by hacking the camera in settings.ini or with SL 1.9's camera functions, but SL just needs an optional, togglable, full-GUI 1st-person view.
reset (discuss): The camera should, optionally, not reset the zoom when moving (walking, flying, etc), and/or clicking on one's avatar, and/or when start/stopping flying, and not reset the rotation (pitch) when coming out of mouselook mode.
sitting
rotation while sitting on:
prim: The camera is locked vertically and can't be rotated when click-dragging on the av, unlike when sitting on the ground.
prim/ground: The camera keyboard horizontal rotation keys invert. Also, holding the up arrow moves the camera closer and eventually into 1st-person view but holding the down arrow doesn't get out of it.
limb distortion: When the camera is focused on something (vs. on the avatar), and escaped out (reset), the avatar's limbs screw up and slowly (about 30 seconds) correct themselves.
As to the Havok-2 project... it has been going slower than I had hoped. The main thing we're trying to accomplish is to eliminate the "deep-think" problem (which is described elsewhere in these forums and is the cause of 99% simulator crashes). We've discovered that deep-think's are still possible in Havok-2 if we are not careful about how we describe the shapes of objects to the physics engine. Fortunately we know how to solve it and that is what we're working on right now. We gave an internal Havok-2 demo to the rest of the office last week where we showed the progress on that front.
When Havok-2 is initially released it won't have many new features. We'll be happy if we manage to prevent deep-thinks and make things run a little faster.
Once Havok-2 is happily doing everything the old physics engine used to do we'll start working on adding new features. Some of the features we'd like to get done are: more complex dynamic objects, better vehicles, new shapes, fixed joints and constraints (hinge, point-to-point, etc), new constraints such as ropes and chains, better collisions between avatars, colliding attachments, and more advanced script sensors such as raycast queries. New features will be released when they are done. (Andrew Linden, 7/17/05)
Ageia is definetly some interesting stuff. Some things to keep in mind:
This technology is not available yet and first-generation anything is rarely reliable/accurate/etc. It is likely to be quite a while before a version of this technology is available that we would feel comfortable relying on.
Integrating a physics engine is not trivial work. Ageia would require a complete reworking of how we deal with and connect to the physics system. As evidenced by our work moving to Havok 2 from Havok 1, this is not something that is easy or can be done quickly.
We have a lot of servers. Adding new hardware to all those systems is a prohibitive factor. There would have to be an immense benefit to warrent such a move. Especially if you consider from the previous points the time frame such an event would occur and our current simulator growth rate. And I don't even want to think about the social issues of only having this hardware in some sims much less the technical issues for passing an object from a simulator with one physics engine to one with another.
The short answer is that we will of course keep our eyes on this technology but it is not currently planned for use in Second Life.
The PPU technology is targeted at gamer desktop applications so its probably going to be an expensive expansion card that gamers can buy to enhance their systems and take advantage of accelerated physics for games that support it (specifically games that do a lot of physics on the local machine -- at the moment SL does all physics server-side).
In the short term (1-2 years) I doubt SL will be jumping on this technology since the PPU systems will probably evolve quickly, be unstable, and/or be expen$ive. We'll probably wait and see.
Cell-CPUs and multi-core CPUs could prove to be a competing technology to the PPU -- potentially making a dedicated PPU add-on card obsolete (anybody remember math-coprocessor cards?). We know these technologies are coming, will be ubiquitous, and that the manufacturers will be looking for killer apps that will drive people to upgrade. Games have traditionally been a huge driver of demand for faster technology, so Intel, IBM, AMD, etc will be probably be interested in writing physics SDKs that are optimized for using their CPUs.
In the medium term (2-5 years) SL could probably start doing some physics simulations on the client for fluff effects and reducing the need for updates from the server. For this stuff SL might be able to take advantage of any PPUs on resident's home machines.
In the long term (5 - 20 years) the PPU, Cell, and multi-core technologies serve to carry Moore's Law into the next generation. The general consensus is that we're approaching the beginning of the end for speed boosts from smaller microcircuitry fabricaton, but that doesn't necessarily mean Moore's Law is going to fail -- paradigm shifts in technology (can anyone say Cell, stacked CPU cores, PPU, embedded programmable gate arrays, optical computing, quantum computing?) will probably continue carry computing speeds forward. We at LL are counting on Moore's Law to remain true for several more cycles. (Andrew Linden, 3/11/05)
The animation state of the avatar has nothing to do with its collision proxy. Sometime after the next generation of physics engine has been installed we will look into colliding the limbs of the avatar with the rest of the world. (Andrew Linden, 5/4/05)
object mass (discuss): Primitives have a set mass that is just too light. Mass doesn't change much unless:
more prims are linked together
a prim is: cut (path, profile), hollowed, twisted, hole size, tapered, detal radiused, or revolved
llSetForce and llSetBuoyancy can fake more mass but the physics engine, Havok, tends to make the prim/object "bouncier"--takes longer to settle into place as it vibrates/shakes/jitters around, and even stops at an angle when not fully touching a surface--it's odd. Prim mass should be adjustable via a llSetMass function.
flexible prims: Flexi objects can be effected by sim wind, you can set a modifier for the wind force on a per object basis. (Kelly Linden, 4/4/06)
LOD twitch: Flex prims twitch/reset when their LOD changes.
Steve Linden, 6/12/06, 21:20 via IM: As for LOD causing flex objects to twitch, that's hard to avoid. There are fixes, but we probably won't get to work on them for a while.
springs:
This is definitely one of the features that will go in post Havok-2.
The main problem right now is not the load on the physics engine that springs would produce, but maintenance of the collections of objects of the springy objects. That is, keeping track of the sets of objects that are connected to each other by springs. Havok-1 does not maintain such lists so we would have to write the maintenance code -- Havok-2 automatically maintains such lists.
This is a feature that is actually near and dear to Philip's heart. A loooong time ago, before Havok, we had some springs in our simple physics engine. One problem we had was stability -- if you do simple simulation math and throw a lot of springs together you end up with instabilities. Havok uses implicit methods for solving their "springs" which are a little bit more expensive, but much more stable. (Andrew Linden, 2/16/05)
One of the problems with our current UI system is that it is all hardcoded to some degree and is very difficult for even us to change... time consuming. So we really want to make it easier on ourselves. And, in the process, open up the ability to skin and modify the UI by the residents. The plan is to make the UI more data driven so it loads some config files (XML) and builds the UI based on what they say. If it was totally data driven, then much of what you want could be done. But not all... like detachable windows would be extra stuff, and would have to come later. (Andrew Linden, ~9/18/05)
...there are a lot more UI changes for textures/materials coming in the future, and I'm sure it'll be much more intuitive when we get it all sorted out. (Yedwab Linden, 4/17/06)
[16:32] Robin Linden: If you wait a bit, you can use XML and redesign the UI yourself and sell it. They're working on it now but I don't know the planned release date yet. (6/22/06 IM)
axis transform handles/"gizmos" (the red/green/blue translate/rotate/scale axis controls; name suggestions)
auto-center (vote, discuss): I find it annoying having to move the camera to see the axis transform handles/"gizmos". There should be a way to have the handles automatically stay centered in the current zoomed-in view if they will go out of view. When zoomed out, recentering isn't necessary since the handles will be in view, but having to rotate the camera to even SEE the handles, when building up close, gets annoying!
always-visible (discuss): Whenever the camera is moved with the alt key, the axis transform handles disappear, making it hard to keep things lined up as the camera moves. An option is needed to always keep these on.
dockable/tabbable windows: SL allows various parts of the UI windows (inventory, chat history, IM, minimap, object editor, script editor, etc) to snap to other windows and the screen edges, but they cover up part of the 3D pane, obstructing the view, and making the whole interface seem claustrophobic. I think a better, optional, design would be to have the 3D pane resize according to how the windows are docked (like most Windows UIs work). This is how Active Worlds' interface works (mostly) and it keeps things uncluttered (but could still use some improvement). SL's bottom toolbar (IM, Chat, Friends, Fly, Snapshot, Find, Build, Mini-Map, Map, and Inventory text buttons--which I think should, optionally, be icons with tooltips to greatly reduce the toolbar's width and perhaps positioned elsewhere) already exhibits this behavior but it's not enough. Transparent windows help, but the active window loses it and becomes solid.
For example, my screen resolution is 1024x768 and I have the inventory, IM, and minimap windows open all the time and even with the inventory window at its minimum width and the IM window 5 rows high, this blocks a good bit of the 3D pane--worse with the object editor and chat history windows open. Since the inventory window can easily become very long, it is a prime candidate for dockability and 3D pane adjustment. The object editor window is expandable enough to warrant dockability too.
Check out Active Worlds 4.1 (used in Wells Fargo's Stagecoach Island) to see how this would work--and with dockable/hideable window tabs , and maximum 3D pane . Obviously, with a proper, skinnable interface, it wouldn't have to look like Windows (though I prefer that style). SL's interface colors are fairly customizable but it's a pain.
text-entry field character counter: For text-entry fields with limited character length (like the profile), a character number counter could be implemented.
wordy script menu options: In the Tools menu there are some wordy options that could be optimized a bit:
Set Scripts to Running in Selection -> Run Selected Scripts (saves 15 characters)
Set Scripts to Not Running in Selection -> Stop Selected Scripts (saves 19 characters) or Stop Running Selected Scripts (saves 10 characters)
Or, as Strife Onizuka suggests, a submenu named "Scripts in Selection..." (but I'd suggest "Selection Scripts" to save 3 characters or "Selected Scripts" to save another character) with entries: "Start", "Stop", "Reset", and "Recompile".
multiple tabs: If there are enough multiple tabs to cause the [ < ] [ > ] arrow buttons to appear on either side, they won't disappear when a tab is closed (that no longer causes them to go beyond the IM window width) until about 15 seconds later (and only if a tab is selected).
new message indicators: The current IM session's tab and SL's taskbar button will only flash if the current IM session's tab is in the background. New IM sessions will flash the new IM session's tab and SL taskbar button (if SL is minimized or in the background). New IMs in the current IM session's tab should optionally flash its tab and SL's taskbar button when SL is minimized or in the background.
remove "Start"/"Close" buttons: Double-click group/user to start a chat and use the titlebar "X" icon to close windows.
remove redundant titlebar: When an IM session is started, remove the redundant titlebar with group/user name and "undock window"/close icons (which can be put in the main IM window titlebar). The extra toolbar reduces text lines and is particularly annoying when the IM window is very short (so it doesn't suck up even more of the screen than all the other unintuively hidden windows do).
separate groups and users: Tabs? Gets annoying having to scroll down past groups to get to users every time SL is run.
unnecessary text:
remove "New" from "New Instant Messaging" title: Just "Instant Message" suffices.
remove "New IM" bottom tab when no chats are open: It doesn't do anything anyway.
alternate design: Combine IM and "Friends" window for IMs and resize it like the inventory window, dump the excess space between buttons (use icons instead), lose the "Close" button, and show online users at top like IM window. User-specific buttons could appear when a user is selected and stay hidden, or disabled when a group is selected (or, instead of "Profile", open the group info ("Info" icon) window.
I believe better inventory tools will be forthcoming. I might have seen a demo of multi select/delete working a few weeks ago ;-) Also, someone is working on a export/import system where you would be able to make local backups of stuff that you created and own, but that won't be in 1.7 (or if it IS in 1.7 it will be incomplete).
I would expect the free inventory theshold to be adequate for most people's needs, however I don't know the average size of inventory, nor what the inventory size distribution curve looks like. I'm sure that if we were to try to implement such a system whoever was in charge of setting the values and costs would try to pick reasonable values. You know the phenomena where 10% of the population use up 90% of the resouces? I supect the inventory size distribution would exhibit that behavior.
Someone who wanted a large inventory might opt to just pay for the extra storage. I'd also expect the price of such a service to be affordable enough to be used by many while still providing incentives that would convice many others to maintain a reasonable inventory (i.e. removing V1.03 of ObjectFoo when they are currently working out the bugs on V3.25).
Anyway, this isn't on the roadmap that I know of, just something that we've discussed and are thinking about.
...
The main reason why [saving inventories locally vs. on the server] would not be possible is because not all of your inventory is fully permissive -- we would only be able to store stuff that is 100% owned by you. However, if we did allow you to store your own creations locally, then you could then modify them locally and possibly re-upload the result as a new item. (Andrew Linden, 6/29/05)
animation: Since SL 1.6, the inventory takes longer to scroll when moving things and it slide-animates when opening/closing a folder. SL 1.9 introduced silly folder arrows (see below) that take forever to animate when a file is held over them waiting for the folder to open. Why make SL lag even more for such unnecessary animation effects? An option is needed to disable that fluff crap and put SL's inventory back the way it was in 1.5 when it was faster and more responsive.
auto-sort on creation/edit (discuss): When an inventory item is created/renamed, an option is needed to automatically sort the item by name or date depending on the setting--and keep the item selected. It's annoying having to do it manually after each rename.
colors: The dark grey open folder backgrounds (and white outlines around them) are also too bright and detract from seeing the inventory's contents. A colors_base.ini setting for this would be sufficient.
folder arrows: For some reason, LL decided to change the standard Windows +/- closed/open folder indicators with larger Mac-style white arrows. However, these are too big and bright on the black/dark inventory pane background and detract from seeing the inventory's contents. The bright yellow folder icons are bad enough without these folder arrows causing the inventory to look even more cluttered.
gestures: Can't (de)activate more than 1 at a time. Lame.
longer rename field: When an inventory item is renamed, the field is too short (21 characters), making it annoying to rename longer names.
"Inventory Item Properties" window: This window should, in theory, be the exact same size and have the same contents as the object editor's "General" tab, but it doesn't.
object/prim count: It's annoying having to rez the object before it will show the object/prim counts in its properties. The object editor "general" tab lists these so why not the inventory item properties?
reduce/enlarge height when folders are closed/opened: To eliminate excess empty space.
reduce width to maximum folder/file name width: Optionally within user-resized width--if inventory window width set to 200 pixels, don't resize beyond that but only within it.
remove excess space around "Show All" and "Filters" buttons: Or, better yet, create icons and use the titles as tooltips to make the buttons even smaller.
split into 2 panes: folders and files to make navigation easier and significantly reduce vertical scrolling.
Object Editor: For comparisons, mouseover tabs for my versions and click tabs for original versions (only "General" and "Features" change, currently).
Top (Mode) Pane: Bold the selected mode's text and put a horizontal line in between the mode icons (menu options) and text and other options.
Edit
Move the object coordinates "popup" (X: ###.### Y: ###.### Z: ###.###) data from the top center of the 3D pane to the object edit window (to left of "More >"/"< Less" button, for example) so it can't be covered by other windows. The chat background opacity setting should also apply to it (if it's left where it is--but at least move it up flush with the top of the menubar).
Tab Pane
General: Reduced wordiness ("can", "when", etc) and made it more efficient and intuitive.
Description: Note the lack of the redundant "(No Description)" text. It's obvious, if the field is blank, there is no description...the same should be for other inventory items (textures, sounds, animations, gestures, etc); gets annoying having to clear it all the time, only to have it reappear later, randomly.
Photo: Add a photo of the object that the resident can add from their inventory (and not be charged L$ for it).
"Creator", "Owner", "Group" buttons: Convienent resident profile (or group info) access and reduces the need for separate buttons.
"Aquired", "Created", "Modified": The inventory item properties window has the "acquired" date/time but the others are needed too.
Permissions: Section clearly outlined and organized appropriately
Sit/Touch Text: This section is a quick way to change the sit/touch text without having to use the llSetSitText and llSetTouchText functions. Obviously, a script will override these settings.
Object: Rename to "Prim"?
Remove "Edit object parameters:": It's obvious this tab is about editing object parameters; this text is unnecesary.
"Hover Text": This section is a quick way to add hover text without having to use the llSetText function. Obviously, a script using this function will override these settings.
script-specific controls: Disabled "s" rotation field and checkboxes
Features:
Remove "Edit object parameters:": It's obvious this tab is about editing object features (despite them not actually being in the "Object" tab); this text is also unnecesary.
Light: Color - make preview image the same size as in "Texture" tab and add a "Same as Primitive" option to use the prim's color (which will then disable/greyout the light color preview image.
Smooth Rotation (°): Since llTargetOmega is a client-side effect, and since "flexible path" and "light" are already here (and have comparable LSL functions to control them), I figure smooth rotation should be too (and smooth movement eventually when it's added to SL--hint, hint, LL...).
Texture:
Repeats per Meter: Lose the "Apply" button; just automatically apply the change like every other setting.
Align: Expand with full text ("Align Media Texture") to remove duplicate "align" text and put "(must load first") on the same line--if this text is even necessary since the button is disabled until the texture is loaded anyway.
Smooth Animation: Like "Smooth Rotation" above, this section is for another client-side function, llSetTextureAnim. While more complex than llTargetOmega, it's still implementable in the object editor.
Content: Change the "New Script..." button (which opens up the script window) to "<< New Script" which expands the object editor to include the GUI script editor (see below). A separate particle editor will then expand off the script editor.
Script Editor
GUI Editor: This design is similar to my redesign of the Active Worlds Object Properties window but far more complex: a dynamic, intuitive, well-designed graphical user interface to create a script without having to learn complicated programming-level syntax and structure by using a branching tree layout to represent code blocks--without writing any code. The script editor window is an extension to the object editor and will pop (not slide) out on the left. Since many script functions mimick object editor functions, the object editor tabs can be utilized for most functions (which will enable/disable controls relative to the selected script mode--see below).
Another way to present scripting is to start out with what the user wants to do (set something, get something, etc) then ask when that will happen (on rez, when touched, if the object hits something, etc). With just simple language, higher-level functionality can be translated down into lower-level code. Of course, more complex scripts will most likely require code-level editing but for many simple scripts, this GUI editor should suffice.
Window layout: title bar (window name, context-sensitive help that opens up to the appropriate LSL Wiki web page, and minimize/close buttons), menu bar (with "Source..." option in "Edit" menu to view the script's source code), status bar, 3 panes:
Code block tree
Branches: (like the inventory with icons) colored for each state, event, function, and flow control statement, and single entries for groups of local/global variables (scope-position-dependent).
Punctuation: Braces {}, semi-colons (;), brackets [], commas (,), and other punctuation are unnecessary since automatic branch indentation shows program flow and UI controls will handle multiple items (as in lists). The underlying code will still use punctuation, of course.
Example:
default
state entry
Set Text
touch start
if (condition)
statement
else
Automatically resizes relative to contents.
Supports standard multi-select context menu options:
Status/buttons: Errors, tooltip info (since it can stay visible longer and won't have linewrap issues), and expanded tree entry info (i.e. click on a function and the status area shows all of its parameters in code form).
Categorization: The LSL Wiki already categorizes everything so I will use that as a starting point.
Functions: Remove "ll" from names and focus on a more intuitive naming scheme (spaces between words, complete words: "Params" to "Parameters", etc) to make it easier to figure out what one wants to do: Group them by different types: get/set, remove, start/stop, etc. Provide a way to switch between alphabetical and categorical lists. Obvously, the underlying LSL functions will remain named the same.
Events: Remove the underscore (_).
Functions/Events: Sort by category like: agent/avatar, camera, communication, collision, etc.
Script flow/mode: Different modes will allow the script editor to remember and store each entry in the tree. Once an entry is complete, the <-' (enter) button is clicked to add it to the tree.
tree entry: Select a line/branch in the tree to have its parameters/values loaded into the right pane.
state: Because scripts use states, that is usually the first thing the user will select. Obviously, default is the first state and will be assumed--hence, the user won't need to do anything to begin in this state. The user can simply begin choosing things to do (events, functions, etc). However, a text-entry field for a custom-named state should be here.
event: Sort type (alphabetical, categorical, etc)-selectable pull-down list
function: When a function is selected, the window controls update (hide/show/change) accordingly: constants pull-down list contents change according to function, etc.
Examples
llSetText: Takes a string text, vector color, and float alpha.
Select "set text" from the function list.
Enter the text in the "text" field (or choose from the "variable" pull-down list).
Click the "enter" (<-') button to add the entry to the tree.
llSetTexture: Takes a string texture name and an integer side.
Select "set texture" from the function list.
Because a standard texture picker image button is more intuitive than having to type a texture name, the object editor "texture" tab) will be used to select the texture. (A text-entry field is still present but shouldn't be necessary with a well-designed texture/key picker).
Since ALL_SIDES is a constant, only it needs to appear in the constants list. However, since it is a fairly common constant, it can just be represented by an "all sides" checkbox instead. Or, even better (and more intuitive) use the "select texture" mode in the object editor: for all sides, the entire prim is selected; for a specific side(s), the prim's sides are clicked on and the script editor will save each side into a list (or multiple calls since this function can't handle a list type for side).
llRot2*(llGetRot()): click the radio button next to the position axis
Variable
type: Normally, instead of having fields named for types like integer, float, vector, the UI controls will change relative to the function. See below for examples. However, a variable type pull-down menu is still present.
key: Since a key is used mostly as a target, the "key" field is directly under the "target" pull-down list (which has standard target keys for the object, object owner, script owner, and an inventory item--which will show another pull-down list of any items in the prim's inventory).
list: A table of list entries can be shown instead of (or as an additional option to) showing a list as [1,2.0,<1,2,3>].
type
name
value
integer
name1
1
float
name2
2.0
vector
name3
<1,2,3>
rotation: All rotation is automatically converted to Euler by default but the quaternion "s" value is also present.
string: Uses the "text" field exclusively but since anything can be converted (typecast) to a string, a function or variable can be selected too.
vector: Uses object editor's "Object" tab's "position" field which changes name according to what the vector is for: position, direction, velocity, force, impulse, target, etc. Euler format rotation (which is a vector) is handled as described above. Scale has its own separate fields like normal.
name: Text-entry field for custom variables.
global: Checkbox for a global variable (which will put it in the "global variables" branch).
"Script Search" window: There's no indication if no result is found. The window needs a status bar (perhaps use the main script window's bottom status pane) to indicate no results found. Needs an option to match on whole word only. Regular expressions would be nice too.
width: Can't be narrowed less than a certain width so it takes up even MORE of the screen than it did prior to SL 1.9. Fixed in SL 1.9.1.9 (1 month later)! However, it still can't be as narrow as it used to be... (and is 2 pixels wider in SL 1.10.4).
Profile: For comparisons, mouseover tabs for my versions and click tabs for original versions.
inconsistent text field sizes: On the "2nd Life" tab, the "About" field holds 500 characters yet is shorter than the "1st Life" tab's "Info" field, which only holds 250 characters. Oddly, the "My Notes" tab's only text field doesn't state how many characters it can hold yet is the longest text field but goes beyond the width borders of the other tabs (as does the "Picks" tab's UI elements). These improvements maximize text field space:
all tabs: Move other-resident profile buttons ("Show on map", "Instant Message...", "Rate...", "Pay...", "Offer Teleport...", "Mute") down to overlap "OK" and "Cancel" buttons for a resident's own profile. Mouseover image's buttons to see this.
2nd Life: Shorten "ratings" section and list multi-column (especially since negative ratings are no more). This will break up the list of received ratings ("behavior", "appearance", and "building") vs. given ones but it's not that big a deal.
Interests
Change "I Want To" to "Desires" to be consistent with "Skills" (vs. "I Can Do" or something stupid like that).
Expand text fields for these sections to use the full window and add character limit.
Replace "Modeling" with "3D Modeling" to skill option since "modeling" is often confused with photoshoot/runway modeling.
1st Life
Add second photo since there's enough space.
Expand text field to use the full window.
My Notes
Center text.
Expand text field to use the full window and add character limit.
edit particles: The particles that emit from an avatar's hand when editing something can be very distracting--especially when zoomed in and even more especially when working on particles (and still even yet still more especially when zoomed in close!). An option is needed to disable these completely (without mindlessly disabling all particles). Also, the particles should simply scale down to 0 as they move towards their target.
floating point rounding errors (discuss): SL's full of them, from grid position irregularities to the object editor dialog, which is particularly annoying when it decides to round cuts and other prim parameters. Of course that started happening with the dreaded SL 1.7 release, too, I think.
integrated modeller: If SL is going to be accepted in the mainstream it must support object importing. Otherwise, it remains propietary and, essentially, worthless. This is what happened to Active Worlds (AW) and its use of RWX (RenderWare script) from Criterion, who dropped support for RWX in RW3. Criterion replaced RWX with DFF but I heard even THAT format will be discontinued. The point is: propietary formats suck. 3DS (3D Studio) is a common format that's been around for at least a decade or 2. For SL not to at least support that is just stupid and foolish. SL doesn't have to allow physics in imported models (right away) or even anything simple like changing overall color/texture (like AW does) but even those would be trivial.
The problem is: SL has an integrated "modeller" but it just sucks. SL tries to do too many things. While I would love to see an integrated 3DS Max-level modeller in SL, until LL and Autodesk (3DS Max's developer) team up, I doubt that'll happen anytime soon (but it should--and it will in another app eventually).
Obviously, collaborative modelling is where 3D is heading towards, as is evidenced by 3DS Max's continued addition of asset management sharing. It's only a matter of time before multiple users can model simutaneously, creating the scene in real-time--just like a movie set. The integration of movies and 3D animation will only push this even further. Pixar's RenderMan may already have this capability, but Maya and Max (both now owned by Autodesk) are used extensively and are more popular.
Will Autodesk eventually buy LL/SL and integrate some of its features? Who knows. But collaborative environment editing is the future so LL better get on the ball and position itself now before it's left in the dust like AW...
primitives limitations (discuss): Why only primitives? Objects can be as simple as a single polygon or as complex as an infinite amount of polygons--it all depends on the modeller. But the problem with primitives is all of the wasted, covered polygons which unnecessarily contribute to decreased framerate. For example, butting up 2 cubes together covers 2 sides (4 polygons). Also, since 2 cubes are now together, their sides (2 polygons per face x2 = 4 polygons) can be reduced further (only 2 polygons), eliminating more polygons.
Creating walkways (sidewalks, roads, paths, etc) by butting up cubes wastes a lot of polygons--and the undersides are usually unnecessary, too. SL can really start lagging with all of the wasted polygons and it would at least be nice to be able to delete and merge primitive polygons/faces/sides/whatever. Also, why no way to specify the number of sides of a primitive? Spheres, torii, cylinders, cones, etc are very wasteful of polys... Puzzles are fine but building LEGO-style is a very wasteful method of 3D modelling if it's not designed to be efficient and optimized for rendering.
SL needs to optimize its primitive parametric modelling to remove hidden/covered sides/faces and allow for finer control over how many polygons a primitive can have--particularly for more complex shapes like spheres, torii, etc (and cuts/twists).
Supposedly, SL is planned for an "ambitious overhaul of the primitive set" (Andrew Linden, 3/13/6).
client-side vs. server-side: SL needs more client-side functions for most, if not all, functions. Not everything needs to be server-side. Everyone doesn't need to have everything in-sync with everyone else. Movement, rotation, scaling, prim parameters, sun/moon movement, lights, etc, could all be animated much smoother if client-side (and no stupid delays!). Active Worlds does this and it works well--and AW4 even has a new "global" command where everyone (in visible range, of course) sees/hears the same smooth effect. Interpolate server-side values so the client always sees things smoothly.
particle editor: Scripting is fine but there's no reason a GUI particle editor can't be created. It would (optionally) automatically change the particles in real-time (since they are a client-side effect) when a parameter is changed without having to hit the "save" button all the time to see changes. However, saving the parameters would then upload them to the asset server (which is slower) for everyone to see.
angle diagram: Because visualizing radian angles can be...annoying, a simple circle diagram shows the angle. Better yet, dump radians and just use degrees (but still keep the diagram).
alpha/transparency fade in and out
(vote, discuss): Particles should fade in and out without having to use scale tricks (since that restricts particle scaling). A new llParticleSystem constant, PSYS_PART_MID_ALPHA, could be added for the MIDdle alpha to allow smooth alpha/transparency particle fading both in and out. Separate fade in/out times (separate from particle age) would be cool too; Active Worlds has these parameters.
middle scale: Like with alpha fading in and out, particles should have a PSYS_PART_MID_SCALE since only one of the scale parameters (PSYS_PART_START_SCALE and PSYS_PART_END_SCALE) can be <0,0,0> while the other can't be less than <.03125,.03125,0> or particles won't even render. Start/middle/end scale times would be great too.
type: SL particles can only be one type: sprite (always faces the camera no matter what the angle). However, there are other types that can be supported (and that Active Worlds supports) like facer (similar to sprite but always faces the avatar, not the camera), flat panel (a depthless, 0-thickness plane that can be rotated into any position), and a model (prim/object in SL terms, that shouldn't count against parcel/sim prim count, of course, since particles only last a certain amount of time).
use camera position: Center particles on each user's camera, like Active Worlds has: "Normally particles appear within a box as defined by the emitter's volume (see below). However, you may enable this option to move the spawning area from the emitter to the camera. The effect will be that particles will seem to come from all around the user, wherever they go. This is ideal for creating weather effects." (source)
llTargetOmega synchronized rotation: Since this function is client-side, it quickly gets out of sync if the prim the script is in is selected (which can stop or slow the rotation, depending on which prim is selected) or if SL is minimized or the used switches to another app.
...more generalized clothes layers (so that avatars aren't limited to just undershirt, shirt, and jacket), better animation tools, better hair, and cloth dynamics. (Andrew Linden, 11/19/05)
appearance
height: Avatar shape can't be under ~2m. Why? They should be able to go down to 0 and completely invisible if desires. Taller too.
cuff flare: Clothes > Pants > Cuff Flare isn't tight enough with 100 "Pants Length" (long) and 100 "Pants Fit" (loose). The cuffs are still too flared.
attachments: more attachment points
I think the attachment system is currently maxed out in its present design, but I suspect that Richard Linden has a plan for making it better. (Andrew Linden, ~9/18/05)
This is a bug... of sorts. What is really happening is that all modifications of the avatar go through a particular path in the code that also tries to rescale the avatar's size. The reason all of the avatar changes are grouped together in one spot is that back in the day we didn't have drag-and-drop outfit changes -- the only way to change your clothes was to go into Appearance Edit mode. Since you can change your size in Appearance Mode and back then we didn't have code to handle resizing the avatar while it is sitting you would be forced to stand first.
As to hosting simulator engines on private hardware, I think that will happen, but it is one of those things that is years away. All of this other stuff (MONO API, data-driven UI) has to happen first and most people don't have enough outgoing bandwidth to support their own sim today anyway but you can be sure that the bandwidth capabilities will happen. Trusted protocols will be needed. We do have plans to decentralize SL. We only have so much room in our colocation facility and there aren't many colos bigger than the one we're in. (Andrew Linden, ~9/18/05)
RealityPrime: SL's apparent original 3D engine core developer
Developed real-time "global illumination" (simplified radiosity) with thousands of movable lights and shadows, optimized visibility culling, and advanced hardware rendering optimizations.
Developed fully procedural object creation and editing, optimized character animation, and other special effects.
Tips/Tricks
Improvements
Links
News/Updates | 
