Thursday, November 23, 2006

Unheavenly Bodies

The sun and moon in Second Life are unrealistic and just plain ugly.

That's right, I said it. I went there. Ugly!

Figure A.


As I see it, there are three main problems with Second Life's sun and moon:
  1. Their reflections on water stretch unrealistically.
  2. They sometimes appear as dark or darker than the sky around them.
  3. Background stars are drawn in front of them.
Examine Figure A; the left half is raw, untouched snapshot of a near-sunset in SL at 300m; the right half is what I think it should look like. (NB: the bottom of the reflection is partially obscured by clouds.) Both problems 1 and 2 are in full force here.

Figure B.

Optics minilesson #1: In the real world, a reflection of the sun or moon on the water appears stretched because of small irregularities (i.e. ripples) on the surface of the water which change the angle at which light is reflected. You can see this in Figure B, a test image I rendered in Blender using raytraced reflections. The image shows a lit sphere resting on a perfectly reflective surface. On the left side, the mirror is completely smooth; note that no stretching occurs in the reflection. On the right side, however, the mirror has small ripples which affect the angle of reflection, causing the same type of stretching seen in the real world.

My graphics card is not powerful enough to enable fancy water, so I, like many Residents, simply see an upside down and yuckily stretched version of the sun or moon in the water. I know the programmer who did that meant well—he or she just wanted to make it look as if there were ripples distorting the reflection. But all it accomplished was making it look like the Grid is a concave Discworld.

Optics Minilesson #2: In the real world, the sun can never appear as dark or darker than the surrounding sky for the simple reason that the brightness of the sky is due to partial scattering of the light from the sun. Most of the light from the sun passes through the atmosphere without much scattering, which is why the sun appears to be a circle with definite edges, rather than a vague patch of brightness.

Figure C.

Optics Minilesson #3: The moon, too, will always appear at least as bright as the sky around it, never darker (as it does in the left half of Figure C). This is especially obvious on days when the moon is visible during the early morning or late afternoon; the unlit parts of the moon, which would appear black at night, appear the color of the sky.

Why does this occur, when mountains and skyscrapers do appear dark against the sky? Quite simply, because mountains and skyscrapers block the scattered light from the sky. The moon, because it is outside the atmosphere, does not block it.

Also note in Figure C the star appearing in front of the moon. That's just crazy.

Tuesday, November 21, 2006

Oi, clients.

This is not a rant. This is a cautionary tale.

I have done all my ranting about this issue in private conversation; ranting in public would do nothing to help it. I will not be naming names, and I ask that anyone familiar with the situation refrain from the temptation as well. I am not writing this to attack any individual, but as a general warning to others, and a reminder to my future self.

Over the past month, I have been working with an individual, "X", to thrash out the design for a large-scale building project. We went through several iterations of the design as I began to understand what X wanted. Finally, X was satisfied with the direction I was taking the design, and asked me to submit a formal bid—how long it would take to build, and how much I would charge to build it.

I mulled it over for a couple days, and sent my bid to X: estimates for what work I would be doing, how many hours each part of the work would take, when I would start construction, and when construction would be complete—along with my fee (regardless of how long it actually took to build). Given the number of hours of work estimated, I was charging about US $15/hour for construction, texture treatment, and scripting (my design allowed for the layout of the building to easily change with the client's needs).

It was, from my point of view, a fair offer. Given the scope of the project and the skills involved, I could have asked for much more than that. However, I am not a big-name well-established builder, so there is some amount of risk, from the client's viewpoint, that what I deliver would not meet the client's expectations. I took this risk into account in my fee, among many other risks on both sides. Confident that my offer was reasonable, I sent my bid to X.

To put it nicely, X was not prepared to pay what I asked, and rejected my bid.

To put it accurately, X snidely accused me of charging an excessive amount for my services and dismissed me without any further discussion.

X, it seems, would not pay more than a certain amount which, given the number of hours I had estimated as necessary, came out to less than US $3.50 per hour. Upon hearing this, I (trying to remain civil) asked X for verification of that rate, and asked if the number of hours I was estimating was, perhaps, more than would be necessary to achieve X's vision. X refused to discuss it.

Now, X had been a difficult client to work with during the design phase. X's "requirements" were vague, and in some cases contradictory or simply impossible given the realities of three-dimensional space. (On the other hand, if I were building for four-dimensional space, such pithy concerns as distance and volume could be ignored). I was warned by another builder who had worked with X. I had no reason to expect X to act rationally, but hope springs eternal.

The lessons I have learned (or had reinforced) are:

  1. Make sure the client knows what he/she wants before you begin, and can communicate it to you. Otherwise, you are trying to hit an unknown and possibly moving target, which is quite frustrating! It also increases the likelihood that the client will pull something new out of their hat halfway through the process.
  2. If you are designing a build in addition to constructing it, treat them as separate processes, and charge separately. Planning the design before you build is good on general principle, of course, and treating them as separate processes helps enforce that. On top of that, it ensures that you will be paid for the design work, even if the client changes his/her mind about hiring you for the building. I also recommend charging as-you-go for each revision of the design if possible, for the same reason.
  3. If the client is full of drama before you are working for them, they will probably be even more full of it while you are. If drama, headaches, and frustration are what you are searching for, this is good news. On the other hand, if you value your sanity, pass up that client.
  4. Contracts protect both sides. Write up contracts for every step of the way, outlining the expectations of both parties, and what should happen if those expectations are not met. Have the client sign/agree to each contract, then stick to it.

Sunday, November 12, 2006

Linden Lab to Instructors: kthxbye

Linden Lab recently announced that it would be ceasing the instructor subsidy program effective December 9—after that date, Linden Lab will no longer pay L$500 per class an Instructor teaches.

Apparently, this both upset and surprised a number of instructors! To them, this is the latest in a series of moves by Linden Lab to destroy everything we used to love about Second Life.

Me? I don't really care. I have never requested any subsidy payments for my teaching. I don't want hand-outs, and I'm not teaching as a favor to Linden Lab, so they can keep their money.

I take tips from students. At the end of (almost) every class, I mention that I do take tips, and that a contribution of any size is a good way to tell me that you appreciated the class—but that the class is free, and tips are entirely optional. I get paid iff my students think what I have taught them is worth paying me for.

On only one occasion have I received more in tips than I would have received as a subsidy payment; usually I receive about half. But I know I earned it.

There are two factors which, one might argue, make my situation unusual among instructors (and thus renders my opinion on this matter entirely invalid).

  1. I do not teach in SL as my means of survival. (I teach because I enjoy it, and to make a bit of spending money.)
  2. The material I teach is not geared towards newbies, but instead Residents who have been in-world for a while and wish to improve their skills for personal or commercial benefit. (Oldbies and professional builders are apparently more likely to have money on hand with which to tip someone who teaches them techniques to improve their building efficiency.)
"Of course you don't mind," writes an imaginary instructor. "You don't need the money, and besides, the way you teach is more profitable! I, on the other hand, have to teach a hundred newbies to put on their own pants just to make enough money to buy a pre-owned can of chicken broth!"

Yes, it's true: instructors who have been surviving on hand-outs from Linden Lab in return for teaching newbies the utter basics are getting the shaft. Tough break for you? My only advice is to adapt your business model. Find a business to sponsor your class. Start charging for admission. Teach something that people with money will pay you to teach.

Linden Lab is, in some ways, giving themselves and every Resident on the Grid the long-term shaft, too. Hordes of the unwashed masses are already trampling everything; now they will be unwashed, uneducated masses! Terrible, disgusting plebians whose purest motive in SL is to figure out how to attach a giant penis to their own forehead and find the nearest free sex community.

Boy, the Grid is going to /dev/null in a handbasket, I tell ya. It's enough to make me yearn for ye dayes of olde when a prim was a just a prim, grass textures were greener and never had to rez, and every Resident descended onto Help Island from the immaculate Skybox of knowledge and dedication.

Those were the days.

Monday, November 06, 2006


This is all.


(It's enough.)

Saturday, November 04, 2006

Chat Range

There is still one more part of Color Curves yet to be written, but it requires significant research and development into methods of algorithmically generating intermediary control points between the two blended colors, taking into account neighboring control points. (For the transition between two curves to be visually smooth, it must be continuous, which means that the end point and the control points on either side must be collinear, i.e. they are all in a straight line.)

But that is a post for another day. Today's post requires much less education in maths to understand. The topic: chat ranges!

Right now, avatars have two options for range when it comes to speaking: you can speak normally, in which case anyone (and anything) within 20m of you will hear you; or, you can shout, in which case the range is increased to 100m.

Scripted objects have one additional option, designed to reduce the noise in the chat channel: they can whisper, which carries for only 10m. (Avatars cannot whisper, only scripted objects.)

Being the person that I am, this limitation is dissatisfying to me. What if I want to have a conversation around a dinner table, without disturbing (or being overheard) by the group at the neighboring tables? Or what if I am teaching in a 60m-wide lecture hall, and I want even the students in the back to hear me—but I don't want to bother the people out in the lobby, who are 80m away?

Even if avatars had the whisper option made available to them, the granularity of three choices of range—10m, 20m, or 100m—is unsatisfactory. There are too many situations where something in between (or smaller) is needed.

In some situations, you can work around this with scripted objects. If you need a smaller range, you can attach an object to your avatar which listens for your chat on a hidden channel, and whispers it into chat for you (thus emulating a whisper option for avatars). If you need a range between 20m and 100m, you can set up scripted relay objects, like small intercomm systems which listen to chat in one place, broadcast it on a hidden channel, and then repeat any broadcasts it receives into chat. Both of these solutions are suboptimal.

"Alright, Jacek. Get to the point. Tell us your solution," you say? Oh rude and belligerent imaginary reader, I was just about to tell you!

The solution is this: on the chat bar, in lieu of the "Shout" button, we should have a numeric input box, into which we can type the desired range of our chat. This setting would remain in effect until the next time you changed it; a checkbox toggle in Preferences would determine whether the setting is saved across sessions of SL.

This renders the shout and whisper actions obsolete for the most part, but they do offer something useful which the proposed solution, as presented thus far, lacks: by appearing to other users as "Jacek Antonelli shouts: Yay! Candy!! \o/" or "Considerate Vendorbot whispers: Your purchase of 'Xcite! Interactive Torus Attachment' will be delivered soon.", they convey important information about the range of the chat, and who else can hear it.

It would be simple enough to automatically label chat as whisper, normal, or shout based on range (anything <=10m is whisper, anything >=50m is shout, for example). But we can do so much better—let's let the user define custom ranges and labels for their own chat!

This would be a new tab of the Preferences window. In it, you could define "rules" for determining what label chat will be given, based on range. An example rule might be something like this: >25m, <51m: "calls out". After defining that rule, anything I said with a range greater than 25m but less than 51m would appear like, "Jacek Antonelli calls out: CANNONBALL!! *splash*".

The other logical alternative would be for each user to define rules to label *incoming* chat based on range, rather than labelling their own *outgoing* chat for other people to see. I prefer the latter for its roleplay possibilities (you can easily establish a "personality" for your avatar based on how you label what you say), but the former would offer more uniformity in what each user sees (you won't have to figure out what the heck so-and-so meant when they "burbledummed" bad jokes at everybody in the room). For the best of both worlds, checkbox preferences for "accept chat labels from other users" and "apply custom labels to incoming chat" could be offered to let each user decide.

There is one more aspect of this feature proposal: remap the Ctrl-Enter keyboard command to send chat with a user-defined range. This way, users could decide whether Ctrl-Enter should send chat with a wide range (like the current Shout action does), a normal range, or a short range. Sending chat with Ctrl-Enter would not reset the range for other chat, so you could use it for those times when you want to send one or two lines of chat at a different range than the rest of your conversation. (For example, you are talking to your date across the dinner table, but you want to call out a song request with a normal chat range, then continue whispering sweet nothings.)