09 April 2012

Building with mesh

I've been skeptical that I'd be able to deal with building with mesh ever since it was announced. I didn't see the point, and didn't think the tools were something I could learn to deal with. Over the past couple of weeks, I've changed my view.

I had thought that the only tool that I could use without spending piles of money I don't have would be Blender. I hate Blender. Blender is as user-friendly as Viewer 2 is popular among long-time SL users. Every time I run it, I want to throw my screen out the window without bothering to open it first. The official tools, like Maya or 3DStudioMax, are far out of my price range.

Then I got interested in sponsoring World Goth Fair 2012, a monthlong event run by my good RL friend Axi Kurmin to benefit the Sophie Lancaster Foundation. That's the kind of charity I can get behind, and I was happy to plunk down the sponsor fee and pledge a substantial portion of sales to the foundation's benefit. There's just one problem: None of my furniture is gothy.

I'm not a goth. I know bupkis about it, myself. My furniture design principles are simple, clean, and functional; I build with 2-inch aluminum plate for a reason. I've gotten pretty good at slinging pims, to the point I prototype that way. I've got a well-developed set of design rules I stick with when building furniture. They won't work for this fair.

I asked Axi at one of her world-famous Wednesday evening 80s sets at Gothika what I needed to do to make gothy furniture. My roommate, an incredibly silly ox by the name of Orvan Taurus (yes, he really is silly. Ask anyone but him.) chimed in with "anodize the aluminum". Axi said "you're not far wrong." Oh, really? Maybe I can do this. Axi showed me some furniture samples and explained what they were derived from. That didn't look too bad, so I whipped up a Gothic equilateral arch out of prims, ran them through a prim oven, and ...it almost came out usable.

Almost. The texturing had obvious seams. The point at the top of the arch where the arc prims met was just terrible-looking. When I applied my standard metal texture, it just plain sucked.

All right, time to bite the bullet and try mesh. Axi had suggested Google SketchUp as a mesh building tool. It was maddening at first, but the learning curve looked like it was actually surmountable. I made up an arch or two and they actually looked good when imported into Second Life.

Still, the project languished, until I realized I had another learning opportunity. Linden Lab was sponsoring a design competition to replace the theater used for Third Party Viewer Developers' meetings, and one of the requirements was that it had to be mesh.

I spent an evening, and then a morning, struggling up SketchUp's learning curve, but finally figured out how to do it. I came up with a simple, functional, usable mesh theater, with seating for 36 and a nice screen to show web pages on via Media on a Prim.


When it was done, I let my friend Helena Lycia at it. She's an experienced, accomplished builder. I thought I'd done well. She showed me I hadn't, and how to fix it so I did. I started out with screwed up physics and a prim equivalent of 209. When she was done, the physics were fixed and the land impact was down to 108. I took her lessons and redid things myself, and while I couldn't make 108, I did get it down to 114.

There's one step I don't like very much, but see the necessity for. SketchUp groups things in such a way that one of the chairs, for example, takes up several actual mesh objects. Helena showed me how to post-process it so that it takes up just one object - but the post-processing has to be done in Blender. Gah. At least it's mechanistic, so I don't have to actually deal with the damned Blender UI for very much.

(Aside: Firestorm doesn't do as well as LL's viewer at uploading mesh and getting the physics right. I'm hoping the Havok sublicense will fix that. There's another problem, too, and it boggles me pretty thoroughly: Analyzing the same mesh object for upload cost and PE 10 times will produce 10 values with more than a 50% difference from one end of the range to the other. How the hell can they make the process THAT nondeterministic?!)

I probably won't win the contest. Another entry is much more impressive technically, and since the contest criteria include "a showpiece of Second Life design", simple and functional won't get it. That's all right. I needed the learning experience.

(EDIT: No, I didn't win. I did pick up the L$1000 runner-up prize, and Oz nabbed a copy of it to put in Hippotropolis, on the other side from the official theater. I'm happy with that outcome.)

Now to go back and build the furniture. I've got a couple of weeks yet, and I'm sure I can build several pieces now that I know how to go about it.

The Lab gets one right

At last Friday's Third Party Viewer developer's meeting, Oz Linden announced an upcoming program to let TPVs sublicense the Havok libraries that LL is using in the viewer. This is a good thing, and LL deserves to be applauded for getting this one right.

LL uses the Havok libraries in the viewer for two things: to do some analysis on mesh objects at upload time to assess their costs on the SL infrastructure in order to assign a prim equivalent (PE) value, and to edit the mesh used for the pathfinding feature currently in development. TPV developers have worked around the first library, with results that are usable if not as good as LL's; the second is very new - large parts are still in development - so that we haven't had a chance to do so yet.

Havok is the physics package used in SL. It's hideously expensive. LL uses it because they have to. TPV developers can't afford it themselves.

I'm very pleased that LL found a way to let TPVs sublicense it. I'm sure it cost them some extra money. It also requires that they place no small amount of trust in TPVs not to let it leak to unauthorized people. For those who think LL would rather see TPVs wiped out, this is a clear demonstration that it's nowhere near that simple.

The sublicense carries with it some pretty substantial restrictions:
  1. The viewer it's part of must be LGPL, or licensed under some other license that allows linking with closed-source libraries. As Oz put it, "we're not going to help you violate the terms of your license." As a practical matter, this means that GPLd viewers need not apply. That, in turn, means that no V1-derived viewer is eligible, since those are all GPLd. The Exodus viewer is not eligible either until they finally relicense themselves under LGPL - which will let them join the TPV community instead of merely taking from it.
  2. Be listed in the TPV Directory. This one matters because it gives LL some recourse if the library leaks. I would presume that each TPV's copy of the library will be stamped in some way that lets the source of a leak be traced.
  3. Be substantially based on current LL code for those things that use Havok. I'm not sure just how strictly this one will be interpreted, but it can be read to mean that the TPV has to be fairly close to the current released LL viewer.
  4. The linked page says "be focused on Second Life". The actual license is stricter than that: paragraph 1.1(b) of the agreement says "Sublicensee must require the Third Party Viewer to connect only to servers owned or operated by the Company". We don't know yet whether we'll have to rip non-SL grid capability out of Firestorm yet to use this license, or if simply disabling the code if the viewer is not connected to SL is sufficient. We're really hoping the latter, as we're not going to drop OSGrid support for this or any other reason. If we can't, we'll have to produce two versions, one with and one without.
I don't see the restrictions - especially number 4 - as being a major deal. Looking at it from LL's perspective, it would make no sense at all for them to spend money on the library sublicense agreement with Havok only to have TPVs use it to help out their competition!

This is a very positive step for LL to take for TPVs. I'm pleased, and hope that more goes this way. It shows a true partnership between the Lab and TPV developers, something that's been lacking ever since the last round of TPV Policy changes.