It’s been a busy, fun week! Starting with an interview with Jack Linden and Dusan Writer on the last Monday talking about meshes, Noam Chomsky on Metanomics last Tuesday, and the actual launch of meshes on Wednesday… it was fun!
Well, meshes are out. In spite of my pessimistic descriptions, Linden Lab did really implement them, and they’re easier to use than I thought:
Watching a 9-minute-video about my old clumsy self trying to manipulate meshes might be too boring, so here are the highlights:
- Go to the Second Life download section. Select the Mesh (Aditi) viewer.
- Log in to Aditi, which is the internal LL name for the Preview Grid.
- Go to Google’s 3D Warehouse.
- Install Google SketchUp. You’ll use it to save non-COLLADA files to the COLLADA format.
That’s pretty much it to get you started, even if, like myself, you’re not a 3D modeller and have no patience (or no time) to become one, and just want to try things out.
Remembering that this is just a beta version, and that Linden Lab very likely will bring out more versions until the final release on the main grid. Still, I was pretty much amazed at one point: it’s very easy to import third-party meshes, i.e. meshes not specifically designed for Second Life, and during the import step, you can even tweak a lot of things after the mesh was done: namely, get the SL viewer to automatically create several levels of detail (LOD) depending on how near/far the mesh is viewed; upload a physical model of the mesh (this is what allows collisions with avatars and other objects) if it differs from the actual mesh; consolidate meshes (many 3D modellers, when creating an object, will create multiple submeshes and tie them to a single COLLADA file — SL allows these meshes to be “stitched together”); upload the textures wrapped around the mesh as normal SL textures; and a lot of optimisations (e.g. more detail, less triangles, faster rezzing, and so on).
Mesh upload is curious, and unless you’re familiar with the interface for importing objects available on all third-party viewers, this might be strange to you. Every submesh in the COLLADA file will become a new item in inventory, one that has a new icon , a yellow triangle like a little Egyptian pyramid. Meshes, by itself, are worthless unless they’re applied to an object first — pretty much like sculpties! But to deal with the alignment problems on the first upload, the SL viewer does something quite clever: it applies meshes to objects automatically and creates a “grouped object” in inventory. If you rezz that “grouped object”, you’ll have all submeshes positioned correctly (and you can then select all the prims — one prim for each submesh — and link them together in a single object).
The actual relation between meshes, submeshes, and prim equivalents (i.e. how many prims the uploaded mesh will actually use) is not very obvious, and documentation is still being produced by Linden Lab. So, a COLLADA file which has 50 submeshes might become 50 prims in Second Life, but each prim might actually “cost” 4-5 prims if each submesh is insanely detailed… allegedly, the upload tool will calculate all of this for you before you spend your L$ in mesh upload (right now, like everything on the Aditi preview grid, there are no upload costs). And according to Jack Linden’s interview last Monday, it’s also not clear who is going to be allowed to upload meshes, and how much they will cost: Linden Lab has toyed with the idea of restricting mesh upload to Premium users and/or users with payment information on file, to make content theft harder: you would only be allowed to upload meshes if you gave Linden Lab some of your personal data. This makes content fraud way harder, as creating batches of anonymous alts for the content piracy rings would be worthless to steal meshes and upload them… of course, content pirates would still be able to steal credit cards and create alt accounts, but that would be a major crime in most countries — far, far more serious than content theft! However, Linden Lab hasn’t made a decision yet. They have a few months to discuss it internally while we play around in the preview grid 🙂
Mesh objects are modifiable just like any other object — just the meshes aren’t editable. Some people, like Prokofy Neva, have pointed out that the huge advantage of prims over meshes is that anyone (not just a professional 3D modeller) can tinker around with prim-based builds, while meshes will be impossible to change once uploaded. This is partially true, but… the truth is, the amount of modifiable objects in Second Life is far smaller than non-mod ones. Sculpties, once uploaded, are also non-mod, even if the object that you apply it to will obviously be moddable. The same will apply to meshes, specially the ones that are composed of several submeshes. Each will be an individual prim, which can be retextured, resized, and repositioned individually — in fact, pretty much like sculpties. For the end-user, it will make little difference if it’s a sculpty or a mesh, except that meshes allow almost limitless design, and can be created with something really simple like Google SketchUp, while sculpties have a lot of limitations in the way they get exported to LL’s very tricky sculpty file format. Sculpties were a clever hack to give people a chance to play with shapes not possible with prim torture, but meshes are universal and can pretty much create everything. And amateurs can have a lot of fun with Google SketchUp, too.
Finally, technical impact. We all expect meshes to seriously reduce lag. I’ll address that after the page break; on the preview grid I didn’t manage to do any thorough measurements and comparisons of lag generated from prims vs. sculpties vs. meshes. Meshes load much faster than sculpties, though — this is visually simple to confirm. Do they also generate more lag or less lag? This is harder to figure out without a “lab environment” with accurate measuring, so I can only report on two approaches — personal perception, and technological background.
Economical impact of meshes
Dusan Writer has been very thoroughly considering both the economical and social impact of meshes in Second Life, and I would refer to his article(s) as excellent references of what all this will mean for Second Life. The most important aspect, however, is to understand that there are three main classes of content creators in Second Life, and each will be impacted differently. Let me quote Dusan, who in turn quotes Jack Linden and many other Linden employees:
- People are already creating content externally using things like Photoshop for textures or creating animations outside of SL.
- So, mesh is no different really – we already have content created externally, so this doesn’t represent a fundamental shift.
- Besides which, there are actually very few content creators compared to content consumers.
The last line pretty much summarises things. This seems to be Linden Lab’s official argument, as Dusan reports Philip to have said pretty much the same thing. My own wild guess is that there are around 100,000 professional content creators in Second Life (which is a staggering number, even considering everything!). By “professional” I mean people that sell their content in SL and expect at least to cover the rent of their shops, or that use SL as a “portfolio” to show off their content for customers, even if they don’t actually sell anything. Contrast that with 1.5 million active users, most of which will be consumers, and 20 million registered users, which, for all purposes, rarely, if ever, log in to SL. The ratio of creators:consumers, if it’s 1:10 or 1:15, would be simply awesome, since on most industries — even blogging! — it’s way lower than that. Still, the principle applies: people seriously creating content in SL are few. The rest are amateurs having fun — and there is nothing against having fun building things!
Professional content creators, like Dusan points out in his article, already use external tools to create their content for SL. Textures, animations, sounds, are all created outside Second Life — and so are, of course, sculpty textures. Even if we’re just talking about modelling buildings (or furniture, or vehicles…), professional content creators don’t do it in SL directly. They get their models done in professional modelling tools — Maya, 3D Studio, Blender — to shape their creations, illuminate them properly to get perfect texturing (which is created with the rendering engines of those tools), then tweak the textures in Photoshop, export part of it as sculpties, and upload everything to SL. There is hardly a fashion designer these days that doesn’t add sclupties to their items (although I understand that a lot don’t do their own sculpties but hire modellers to do them); and, similarly, furniture and buildings, while they might still have some prim torture somewhere in them, are also mostly created outside of Second Life and use a heavy amount of sculpties to add realism.
It’s true that people still buy low-quality items all the time. I still sell a lot of L$10 “gothic” pants which I did in 2005 or 2006 for a friendly newbie 🙂 It’s worthless in quality, compared with what you can get for L$10 these days, but it still sells. It’s also hard to estimate how many low-end, poor-quality content creators (like myself) actually make a living out of SL (I don’t), and how much they will be impacted by meshes. I would say that all of those are actually such a tiny minority that the impact will be zero: they will very likely continue to sell their low quality content as before (I certainly do, to my surprise!), but those sales will have little impact on the overall SL economy anyway…
It’s just a few that will actually feel the “impact” of meshes, and they very likely will be very vocal about it, and exaggerate the importance of the “small amateur” in SL. Let’s be honest, when was the last time you bought a low quality product for L$10-50, when you can get a high-end item (with sculpties and pre-baked textures imported from a Maya rendering) for the same price?
And while sculpties were very very hard to do with “amateur tools” (even though there are some pretty geeky in-world solutions to create sculpties out of prims!), at least Google SketchUp is very easy to use: a friend of mine (long-time Mac fanatic, but who is not yet in SL, at least as far as I know…) is fond to say that Google SketchUp will do for 3D modelling what Mac Paint did for computer-based 2D graphics painting. If he’s right or not, I cannot say, but it’s true that there are lots of easy-to-use 3D modelling tools out there, a lot of which designed for amateurs. All of them will be able (with a bit of tweaking perhaps) to export models that Second Life can use. At least it will be way, way easier than sculpties.
So, if you’re a small content creator who got already scared with sculpties, and tremble with fear about meshes, take it easy: you don’t need to learn Maya, 3D Studio, or Blender to compete. You can simply get free meshes from Google 3D Warehouse or any other similar 3D mesh archive (there are lots), tweak the meshes a bit on Google SketchUp or any similarly simple 3D modelling tool, and upload everything to SL. It’s far, far easier to do that than using sculpties. In fact, before I tried the mesh preview, I thought it would be the other way round, but I’m convinced: this will open up more possibilities, even for amateurs, than sculpties did.
The third group are… educators. Well, Linden Lab pretty much kicked them all out by charging them twice the price (I might write an article on why I think they did that), but a few will remain, because they need the kind of service that Second Life provides — even at the high cost — and that is not yet available (or not reliable enough) in OpenSimulator. OpenSim will certainly fully support COLLADA meshes soon. No, wait, let me correct that statement: just one day after Linden Lab has opened the Aditi preview grid with meshes, OpenSim evangelist and developer Maria Korolov has experimented mesh import in OpenSim too. Of course it’s still buggy and has limitations, but the same applies to LL’s own developments, too. It should be interesting to watch both developments side-by-side 🙂 And if as an educator you’re really, really in a hurry to see how your meshes fare in OpenSim, you can do that now.
Now why are educators so happy about meshes? For two reasons, really. In the past decade, a lot of effort and money has been spent in creating 3D models — it’s not really a “novelty”, and areas from history to architecture to computer programming to education sciences have been producing all those models for the past years. Some universities have really invested a lot in 3D content, but it was mostly employed as “illustration material” for their papers, conferences, and thesis. The possibilities of reusing all that content, and putting it to good use inside a virtual world, instead of merely rendering it on server farms until they got a nice picture (or movie), has caught their attention. Except for Second Life/OpenSim, all other virtual world platforms allowed their content to be reused.
But there is more. Educators routinely exchange 3D models among themselves for their projects… and are intense users of Google Warehouse and other free sources of 3D content. One of the appeals that Second Life had for many educators was that it was already full 0f good content, much of it for free, but… you had no way to use your own models. Other platforms simply allowed you to use the content you already had, and you could simply get more from the free 3D repositories. Meshes in Second Life gives them the best of both worlds — the ability to internally justify using Second Life as the virtual world platform of choice (and thus get funding for it!), re-use their own content instead of learning a new tool (or hiring 3D modellers to port the content over), and, of course, the continued access to an almost-limitless supply of free content from the 3D repositories all over the Internet. And remember that free content matters a lot for educators — most are seriously underfunded and have no choice but to get their content for free. I have to admit some shock when attending an academic conference where one speaker demonstrated to his peers how easy it was to get free content and import it into a certain virtual world platform; when asked about the use of Second Life (which also has plenty of freebies…) they discarded it because, well, there might be some free content, but not a massive amount of it, and certainly not so easily searchable like what you can do on Google Warehouse and similar repositories…
A pity that Linden Lab pretty much pushed educators out of SL — they would certainly be first adopters and the primary users of meshes…
What my video doesn’t show (because I’m no expert) is a another aspect of meshes, which is perhaps even more dramatic: meshes can be rigged — a technology allowing them to be part of the avatar’s skeleton. While completely replacing the standard avatar skeleton is not yet possible, it can be transformed and animated in completely new ways. Unlike what happens with normal attachments (sculpties or not), rigged meshes “flow” with the skeleton’s animation, bending where it should, and adding a new level of realism to avatars. It’s not only for non-human avatars that this is a bliss — even clothes, hair, and even knee-high boots can benefit from rigging, and this allows the same level of realism for clothes and accessories that games, MMORPGs, and virtual worlds like Blue Mars can exhibit. Fashion designers will soon start bringing out jackets, trenchcoats, shawls and boots that will realistically cover the avatar, fluidly moving and bending with the avatar’s motions. No more skirts showing through prims when sitting down 🙂 As soon as this technique gets mastered by fashion designers, it will dramatically change the way we think about clothes — and probably push people to spend more to renovate all their wardrobe. Or, well, to get completely new non-human avatars. It is said that this technique cannot — yet! — give us realistically-looking hands and feet that animate and bend at each joint as it should, but it can probably come closer to that dream. Feet are already often done as sculpties to replace the ugliness of the Linden Lab feet; when done as meshes, specially because Viewer 2 allows parts of the body to be alpha’ed out (without the use of the invisiprim trick), I’m sure we’ll start seeing far better and nicer shoes, too 🙂 Designers like Damien Fate and Washu Zebrastripe and their cute Loco Pocos avatars will be able not only to redesign the way their avatars look and feel like, but they will be able to create much better-fitting clothes and accessories for them, using meshes.
There was some concern that the current clothing model will not fit rigged avatars at all (or just not perfectly enough): they will require to be specially designed for them. This can be both an advantage or a disadvantage. For content creators like Damien and Washu, it means that only Loco Pocos clothes and accessories will fit Loco Pocos avatars, and none other — you’ll be stuck with them to supply you with nice fashion items. But the truth is that this already happens today. Tinies have their own market for clothes, accessories, furniture and even animations, as designers agree on special characteristics and design their items having those special settings in mind. I’m sure that a similar development will happen with rigged avatars. Some designers will make sure that only they will be able to sell accessories and updates to their specific type of rigged avatars, while others will adhere to common guidelines and create content with those guidelines in mind. So, in a sense, instead of a one-size-fits-all model, you’ll see clothes and accessories designed specifically for some rigged avatars. Even outside the virtual world business, this is not uncommon: DAZ3D, which produces awesome human figures for 3D models, also has different types of accessories depending on the figure you’re using: “old” clothes won’t fit the latest generation of 3D human figures, because they have more sophisticated skeletons and meshes and different ways to attach accessories to them. Designers will just need to adapt; sometimes, market fragmentation can lead to more sales — we shall have to see how this evolves in the next year or so.
Social impact of meshes
The biggest worry that has been raised with the whole mesh business is mostly social, although the technical issues (described below) have also been noticed. Almost everybody believes that the economy will get a huge boost: based on what happened in the past, a new technology that allows for better content design has always boosted sales, as content designers bring new items out which were previously impossible to do. We saw that happening with flexiprims and later with sculpties; with meshes, it will just be way more dramatic.
Dusan, Prokofy, and many others simply worry that with meshes proliferating in Second Life it will be the end of collaborative content in Second Life — in the sense we understand it today. Second Life was great because you could get a full-mod freebie, disassemble it to see how it works, and create new things based on that. I certainly benefited a lot from disassembling a gas lamp designed by some Linden in 2002 or 2003, which allowed me to look at the “flame” script inside and understand how particles work. Meshes will not be editable (at least for now, although a JIRA feature request has been set up to ask for mesh editing support; if implemented, it would go a long way to minimise the impact of non-editable items in Second Life) and this would mean that collaboration simply will not happen with mesh-based objects.
The discussion on the comments section of Dusan’s article shows how people feel about this: his readers reject Linden Lab’s notion that “content creators are few” and that most residents, even if they don’t actually sell content, are actively creating it (alone or, more often, with friends), and in some cases (like some niche markets) even selling it, even if they don’t make a profit of it. I personally have my doubts there. It’s true that with some other kinds of externally created content some sharing happens: one amateur creator might buy textures from another one, create a few prims, drop a handful of scripts in it, hire someone to do an animation, and sell the whole ensemble as a new item. This certainly happens today; I was told that a lot of shoe designers, for instance, might not even create their own sculpties, and definitely not the resizing scripts, but assemble the whole overall package from several sources.
Well, the way I see it, the same simply will happen with mesh-based objects too. One of the examples (not shown on the video) was an attempt to bring some mesh-bases shoes into Second Life: I got the base mesh on Google Warehouse and imported it. But I didn’t like the texturing (which was basic) and was looking at the UV map for it to see if I could improve it (content creators are usually good at “painting” UV maps — remember, the “avatar templates” used to do clothing in SL are nothing more than UV maps for the two “standard avatar meshes”, male and female). And since those meshes were relatively easy to mess with Google SketchUp, I could tweak them there, too. So while I have no personal skills nor talent to create a brand new mesh for a pair of shoes, based just on visual observation and messing around with a complex 3D modelling tool, I certainly am able to do simple, minimalist mesh tweaking and subsequent import, and I’m sure that if I can do that, everybody can.
In a sense, it’s not much different from messing around with textures — or animations. Even non-experts might have learned that textures in SL are better uploaded with sizes that are powers of 2. So the least one can do, when uploading an image found somewhere else, is to launch some external image editing software (I use Graphic Converter for the Mac, which is relatively easy to do, and cheaper than Photoshop at any case; and looks far nicer and easier to use than Gimp) and resize images properly for importing into SL. Animations, of course, are way harder to do, and require specialised software (like Maya, Blender… or Poser). Nevertheless, free animation software (like Qavimator, developed specifically for Second Life) can achieve pretty good results for the creative amateur, and it’s something relatively simple (and fun!) to use.
So the argument here is not if you can develop everything inside Second Life or not, but if you can share it and collaborate with others, manipulating assets together. Images, animations, and sounds have to be developed outside SL with specialised tools, and there are both professional tools and amateur tools for them. Once imported, textures, animations, and sounds cannot be tweaked by anyone — but they can be included in other people’s content. This is the key aspect of that “imported” content: while you cannot edit it any longer in SL, you can most definitely give it away for people to place them inside their own content. For instance, collaboration doesn’t occur at the “animation” level — that is, once you receive an animation, it’s a finished product, you cannot change it any longer, there is no way to remove some frames out of it or even change its priority (I soooooo wished to have that feature!!).
One might argue that sounds and animations are not really primary content, but just accessory content, and what counts as “collaborative work” is the ability to fix 3D content — this is, after all, a 3D virtual world, and collaboration and content sharing happens in 3D. Put into other words: sharing prims is what matters inside Second Life.
Well, the issue is really philosophical. Let’s imagine a scenario where builders do, indeed, build collaboratively, and set all perms to all items in the region, so that everybody can really tweak each other’s content. This certainly is possible with prims and scripts. Then someone needs to add a bench where avatars will sit, and requires a sitting animation. While the asset itself, once uploaded to Second Life, will be non-modifiable, the group of builders, in the same sharing attitude, can certainly share the BVH file — outside Second Life. Similarly, if someone thinks it would be best to add a sculpty on the build, everybody might be able to share the uploaded texture, but only the person who uploaded it will be able to make changes to the sculpty itself (except for resizing). Sculpties are often done by high-end 3D modelling tools (because few low-end ones have plugins to export to the sculpty format), which means that even if the original 3D model for the sculpty is shared outside SL, not everybody will have the required tools and/or know-how to tweak it. Nevertheless, it should be easy for content creators, working collaboratively, to share finished animations and sculpties among themselves, and incorporate them in their builds; if the original animations or sculpties require tweaking, they will just have to ask the original creator to change it, and share the uploaded item again.
With meshes it will be pretty much the same thing, except perhaps for a slight tweak: sharing the COLLADA file will allow collaborative builders to play with it in very easy-to-use 3D modelling tools like Google SketchUp. Sure, it’s not the same as playing with a prim-based object in Second Life. Even COLLADA files that have several submeshes, and which will be uploaded as separate assets in SL, will result in a different experience. Sure, you might be able to assemble objects with different meshes together, but you won’t be able, within the SL client, to modify individual sub-meshed objects (except for resizing, re-texturing, etc.).
But how important is that ability? Again, the discussion is mostly philosophical. Except for very specific groups of people, who enjoy setting everything full perms and working on each others’ prims, this way of collaborative work is not so common. Even companies that collaboratively work on the same build, but then sell the whole ensemble to a client, don’t work that way: each specialist does their own tasks, and someone will assemble the result together; but even simple tasks like re-editing a script will be handled by the script programmer, not by the 3D modeller that did, say, the sculpties, even if technically he or she could do that if the script is full perms for the group. But when developing high-quality content — which is assembled from prims, textures, sculpties, animations, sounds, clothing, scripts — specialists will be handling their own content, and just sharing assets to the whole group before delivery. Even “prims and textures” is just broadly painting a picture — furniture and interior design is usually handled by different people than the ones creating the architectural “outside” of a building, and terraforming and gardening is handled by a different team as well. While there are certainly people in SL that are good in developing all kinds of content whatsoever, collaborative work is more often done by specialists in each type of content. A fashion designer doesn’t do furniture as well as a furniture designer; and even though they might share the same toolset as a virtual architect, they rarely, if at all, do their own buildings. You can take a look at the shops in SL — it’s rare that the fashion designer creates his or her own shop, and when they do, you’ll be often surprised how a very talented sculpty boot designer actually has a horrible non-functional shop which is so hard to navigate. That’s just because the talent required for one type of content design is not always (I would even say: rarely!) the right of skill to create buildings, for instance. Specialisation is what produces higher-quality content — that applies to the physical world as well as to the virtual one.
But of course this doesn’t apply to amateurs. They enjoy doing all kinds of content tweaking, no matter what the results are. They’re the ones importing images with 4096×4096 pixels just because they can. They will eagerly assemble 250-prim-houses when just 4 sculpties would do the trick. They are happy with blank textures (which they enjoyed doing!) to be applied on untextured vehicles which they have just bought and tweaked. And so forth: amateurs rarely care about high-quality content, they’re more than happy with the ability to tweak everything, even if the result is plain ugly, non-functional, and very laggy. This is all secondary for them, and, remember, this is by far the largest group in Second Life…
Nevertheless, even among the ugliness of most of the mainland, you’ll see that most people don’t work that way. They buy content (or get some freebies) which is most often non-modify, and just drop it around their property, adding some personal touches here and there, but not really changing the original content. I’m sure that there are exceptions to this, and that we can even count those exceptions, and arrive at “hundreds of thousands” of residents who are happily tweaking full-perm content all the time. It’s not a tiny group — but is it the majority? If it is, I have to spend more time in SL, because it’s not what I see. What the majority of content around SL seems to be is pre-assembled from different sources, most often non-perm, and just stuck together by the owners on their land, with some content added on top of everything (like, say, simple frames for pictures that the land owner has made on their own). Many might invite friends to help them to build together, but in reality, they will be just dropping items out of their inventories and arranging them in-world according to their personal tastes. Now and then some full-perm freebie will be added and tweaked by the team of friends, but these will be exceptions, not the rule. And maybe a few of the group of friends are actually reasonably good content creators themselves and might set their own creations full-perm for the group, not minding that their friends change it (most often breaking it forever…). But is this the mainstream collaborative use of content in SL? If it is, I don’t see it happening in the majority of cases, so I have to agree with the official Linden stance here: most content in SL is not full-perms and is not being modified thoroughly by a majority of users. While there certainly is a lot of full-perm content, and many (as said, hundreds of thousands) of residents are tweaking that full-perm content to their tastes, this is not what happens in the vast majority of all cases.
Linden Lab has long been criticised for paying too much attention to edge cases, and ignoring the majority of users. Let’s see a typical example: the vast majority of residents hate the Viewer 2 UI, but LL is reluctant to let it go. A few (myself included) actually love the Viewer 2 UI, and to explain why, I would have to resort to a discussion of user interface design and human-computer interfaces, as well as principles of software ergonomics, and I’m sure that even so I wouldn’t be able to “persuade” anyone — at some point, subjective factors become prevalent. If good UI design and ergonomics were absolute qualities that we used to evaluate the software products we use, we’d be all using Mac OS X — which is a case study of good UI design, unlike anything that came out of Redmond. Clearly, “theory” is not compelling enough to make a case 🙂 Nevertheless, this is a good example of something which Linden Lab stubbornly refuses to “let go” — because a small minority of residents are actually sensitive to the superiority of the UI design on Viewer 2 (no matter if that “superiority” is purely academic theory, and easily disputed), including of course many Lindens in that group, they feel “justified” to impose that to the majority of users. The same applies to a lot of very strange decisions taken by Linden Lab which only seem to have been implemented to harm the majority of residents — even though a very tiny minority might indeed have been benefited by those decisions. Ruling out the majority by addressing just the edge cases is typical for a Silicon Valley corporation, and LL is just true to their heritage when doing that — constantly.
Surprisingly, with meshes, they seem to adopt the reverse approach. Meshes, in general, will benefit the vast majority of users because of the superior quality of content that can be used, and the ease of upload of millions (billions?) of already existing 3D content, most of which can be created with simple 3D modelling tools like Google SketchUp and don’t require specialised software costing 4 figures to develop. It’s true that a few users — and “few” in this context, as said, might mean “a few hundreds of thousands” — might be negatively affected by the impact of meshes (because they have good prim-gluing skills but no experience in using even the most simple 3D modelling tools). These are the “edge cases” which allegedly has made LL be very careful about when to release meshes into SL, even when the work was pretty much complete. I argue that this is pretty much the same group that already feared the impact of sculpties (which do require way more complex tools to be created!) but, over time, they have dealt with the issue and taken sculpties for granted. It’s also true that there are limits to what you can do with sculpties (and which can be achieved with prims better), while with meshes, there are really no limits, so the “perceived threat” of a fully-meshed world that would shut out prim-gluers is not only real, but will definitely have a measurable impact: in a few years, nobody will wish to use prims except for very specialised (or very simple) tasks. This just mirrors what happened on the 3D modelling world, too — there are still 3D modelling tools that directly support prims. Prim-based modelling, in fact, is not completely dead: sometimes it’s easier to use prim shapes to assemble a complex mesh, by adding and subtracting prims from it — and at the end, the tool will just export the resulting mesh. Now if Linden Lab would just implement that in the Second Life viewer, we’d all be happy…
In short: yes, a few people will be affected by the introduction of meshes (and that number is not “a handful” but more likely “a few hundreds of thousands”), but, in general, the impact on the vast majority of users will be far more positive.
Devaluation of content value and content theft
Meshes, however, introduce two new issues which, even though they also existed with prims, will be far more apparent with meshes on the main grid. They’re closely associated, and Linden Lab actually has been internally discussing (and sometimes asking for comments) the way they might be dealing with them.
Suppose that you’re starting a business in Second Life (or, as an educator, launching a new project) and have no modelling skills — just a solid business sense. You will soon realise that you need a 3D environment to launch your business, be it a shop, a real estate business, a venue to hold live music events, or, well, a training/simulation area for your educational project. The first step to assess is how to get the content for that 3D environment.
There are basically the following options here:
- Develop it on your own, if you have the necessary skills.
- Buy content from existing SL content creators.
- Hire content creators to create the content for you.
- Use freebies.
All four options are very often quoted as being advantages of using Second Life’s platform for your business or your project. Unlike what happens in most environments, you can use any of the options above, or, more likely, a mixed approach. So if you have some programming skills, you might just buy some assorted content, develop your own scripts to place inside them, and eventually hire a builder or two to create something unique for you, if hunting for freebies didn’t get you anything you like, and existing content was not modifiable. All combinations are obviously possible, and a lot of businesses or projects are launched only with freebies, for instance. Corporations (and some educational institutions) might require all content to be created specifically just for them, and thus go with option 3, since they have no time to acquire the required set of skills, and existing content might either not be licensed for the use they will give to it, or simply not fit the requirements. Freebies are a mixed blessing: “full-perm objects” still carry a license and they’re not exactly the same as “public domain”, even though a few items exist which are explicitly labelled as such.
But with meshes, a new option arises, which, until now, was not possible. Most people, used to the billions of items available in Second Life, have no idea that many more exist, as meshes, outside Second Life. And, most important, they’re easily searchable. Quality varies, of course, and not all are currently importable into the preview version of the Mesh Viewer, but, in general, there is really a lot of 3D content out there. Most of it is free, but you can also get it cheaply from sites like Renderosity or DAZ3D — sites where hundreds of thousands of really good 3D modellers publish their work (this will also allow professional 3D modellers, who don’t have the patience to be fully immersed in the virtual world, to start selling their meshes to Second Life residents, even if they never have created an avatar for SL and don’t intend to do so). Some academic repositories also exist, and I’m aware of at least one European project to create high-quality, peer-reviewed, historically accurate 3D models of heritage sites. Universities, specially those which are already familiar with 3D environments, might already have developed their models and have them around for ages, and can now simply import them into SL.
What this means is that for many projects (or businesses), the need to either hire a professional SL developer, or to search for SL content (free or not), might become redundant. Just search the Web, look for the model you wish, and import it. No fuss, and no need to spend L$ to buy content or get expensive modellers to do the work for you. These days, 3D modelling is part of the curriculum of every graphical designer — and there are at least dozens of millions of those around the world. So, instead of being “limited” to existing SL specialists, you can simply get cheap/free content elsewhere and upload it to SL — fully textured, full perms, and ready to go.
Just imagine those wonderful recreations that sometimes appear on Showcase, and which have been painstakingly assembled from individual prims. Most of those recreate historical sites, which have been long since modelled in 3D, and are certainly available “somewhere” for easy upload. Also, 3D scanners are becoming more popular and cheaper — you can get one for US$3000, and, with that, forfeit the need of hiring a SL builder to develop complex items. In fact, for a very large scale project which involves a lot of tiny items for popular use, such a device would make the project insanely cheap — while right now you need expert modellers to glue prims together to give you the desired result, and thus make it more costly.
Most people don’t realise how widespread 3D content is these days, because, the truth is, most of it is not really put to good use! We just see “3D content” as something for specialists — architects, artists, MMOG designers, and, of course, Second Life residents. The truth is that a lot of people create all those fantastic models but have little actual use for them, unless they are MMOG programmers or simply artists loving to do 3D creations. But with Second Life as a possible market of digital goods worth US$0.6 billion annually, I’m not surprised if all those sites will soon have a tag saying “Second Life compatible COLLADA mesh included”. Even that NextEngine 3D scanner might have a “SL compatible” tag attached to it in a few months 🙂
The proliferation of 3D meshes outside SL, once imported into SL, will start to undervalue a lot of content. Clothes and avatar design (and accessories) require complex fitting to get a good, realistic look, so they won’t be affected. But houses, furniture, and all kinds of small accessories will be easily available. These days, for instance, vehicle design in SL requires a lot of expertise to get a realistically looking vehicle in just 31 prims (even though most will be sculpties), because of the limitations imposed by Linden Lab. But 3D meshes of every possible vehicle design have long since been a primary focus of 3D modellers, and it will be just a question of picking up one that “fits” into 31 prim-equivalents. Will that mean that house, furniture, and vehicle designers in SL will be out of business soon? I’m not sure. But that they will start feeling a lot of competition coming from amateurs who just upload finished, high-quality, free meshes… that’s for sure. This is unavoidable.
The reverse side of the coin is making content theft easier. Imagine that a very complex 3D mesh is being developed by, say, an university, to represent a whole castle or similar historical site, and that a student gets access to that mesh, uploads it to SL, and starts selling it like crazy; or that people start hacking their favourite games and export those meshes into SL. Of course you can use CopyBot to steal existing content (and meshes will just be another thing to steal), but the appeal of stealing meshes from popular games is far more exciting — and dangerous: is LL liable or not?
To prevent this from happening, an idea had been floating around for some months, which I originally heard from Pastrami (ex- Linden), long before he was kicked out of SL. Jack Linden seems to confirm that the suggestion is still being discussed but no conclusion has been reached yet. The idea is to limit mesh upload only to Premium accounts (or, at least, just to residents with payment information on file). This has a two-fold impact on limiting content theft: first of all, thieves can be easily identified by Linden Lab (when receiving DMCA claims) or even by law courts (in case a game company sues the content thief). Of course some will just steal credit card information and create alts like before — but this turns a simple lawsuit into a criminal charge, and will only be attempted by die-hard criminals, not by the casual content theft. The only disadvantage is that perfectly legitimate content creators who are unable to verify themselves with Linden Lab will be unable to upload meshes, but in my experience, the number of people who have absolutely no means of validating themselves and are simultaneously unable to use the LindeX are not professional content creators (who love to be paid for their work and will use the LindeX to get some real money for their work!). Again, there might be exceptions, and I’m sure there are thousands of exceptions — but Linden Lab should, once more, ignore the few edge cases and just deal with the majority of users; and those will definitely have some form of validation on file.
If this is what LL will ultimately implement, I foresee very happy content creators — not that copying meshes will be “impossible” (again, nothing can be prevented to be copied, once it’s stored on your personal computer), but enforcing copyright claims will be much simplified, both inside SL and, more importantly, outside it, which should act as a deterrent against the casual pirates.
Technical impact of meshes
This will certainly require much more than my humble perceptions to adequately qualify, and, as tests are being done on Aditi, and Linden lab continues to gather data from all viewers participating in the testing, I hope that they release some reports based on real data. Nevertheless, we can extrapolate from the theoretical impact, and it should be dramatically positive.
Why? Let’s not forget that Second Life is all about meshes (except for avatar impostors!). A prim is just a mesh. The difference is that the mesh is stored locally on the client, and the SL Viewer only gets its position coordinates as well as a series of parameters to apply to it. But SL’s rendering engine is a mesh engine, like all 3D engines. There is nothing but triangles, and that’s what’s processed by the engine and the graphics card.
A plywood cube can have as little as 12 triangles (2 for each face) and just one texture, replicated on all 6 external faces and one internal face. So it’s a very simple mesh and one that is rendered blazingly fast. But most items in SL aren’t plywood cubes. Instead, prim torture deforms the mesh, and, in most cases, keeps adding polygons to it. A mere resize will just make the triangles bigger; but path cut/taper/shear will add more triangles. Many, many triangles. And, of course, if you’re using a torus or a ring, the number of triangles in it will be huge (you can visually confirm this by selecting the Wireframe mode in the SL viewer), as the SL Viewer will create a mesh that fulfils the parameters set on the Build tool.
So the reasoning behind having prims instead of full meshes is not because of the rendering engine, which will just handle meshes anyway: it’s just a way to save bandwidth and storage costs, because SL doesn’t need to store all mesh vertex data (i.e. the triangle points): just the type of basic primitive and the transformations applied to it, which have a fixed amount of parameters and are common to all prims. This saves bandwidth when transmitting complex models, at the cost of some mathematical transformations on the rendering engine which has to convert all that compact information into the appropriate mesh.
Now, storage costs are really negligible these days. Bandwidth is another story: sending the “prim torture” parameters for a very twisted torus just requires a handful of bytes, while sending the whole set of vertex points for a mesh describing that same torus will require much more bandwidth. But… how much more? Right now, figuring out the exact amount is a bit mysterious. Remember that no matter how cool and how complex the mesh will be, there will be an upper limit on triangles to be sent: meshes will be converted to “prim equivalents” before upload, and there will still be an upper limit of 15,000 per sim. To make the calculations more complex, meshes will be uploaded at different levels of detail (LOD), which means that if you’re too far away to see the whole mesh, you’ll just get the “lightest” version first, which should download quickly — as your avatar comes nearer to the object, meshes with increasingly higher levels of detail will be downloaded. This naturally saves bandwidth and is a typical way to save not only bandwidth but also rendering time: it’s worthless to try to display 100,000 triangles on an object which will appear to be 5 x 5 pixels in your screen!
In general, though, I think it’s safe to assume that LL’s algorithms to calculate “prim equivalents” for a mesh will give similar results in bandwidth costs for a mesh than downloading the corresponding assets for the same amount of prims. Thus, a complex mesh with, say, 1,000 “prim equivalents” will take about the same time to download as the asset data (e.g. prim torture parameters) for 1,000 prims. I’m quite sure this will not be exactly the same, but, well, the order of magnitude will the same. Also, while a standard cube and a heavily tortured one have exactly the same bandwidth costs, the rendering costs are entirely another story (specially when they have an alpha’ed texture applied on them!); while a mesh is a mesh. Once you have the data for all the triangles, a mesh will require rendering time directly proportional to the number of triangles; while a heavily tortured torus or ring will take way longer to render than a 1x1x1 plywood cube, even though both will take exactly the same amount of bandwidth to transfer. Thus it’s a trade-off: rendering time and bandwidth requirements for a mesh depend ultimately on the size of the mesh (larger mesh = more triangles = more bandwidth costs = more rendering time), while for prims the bandwidth cost is exactly the same, but the rendering costs vary wildly depending on the level of prim torture (which creates far larger meshes for that prim).
But then there is a huge cost saving on complex objects. I’m sure that Linden Lab has some statistics saying how many prims, on average, an object has — if we look at prim hair and boots, I’m sure that 50-100 are average 🙂 Multi-prim objects, although taking the same amount of time to download as individual prims all added up together, are also differently dealt with. First, in terms of physics — and remember this doesn’t apply merely to the special effects enabled by the physics setting on the Build tool; when avatars walk over an object, even if it is not set to physical, this will require handling by the physics engine underneath (which has to validate, for instance, that the object hasn’t a “hole” for the avatar to fall through it). Secondly, in terms of occlusion. And thirdly, in terms of texturing.
The impact of the physics engine is hard to estimate, because physics are “approximated” by bounding boxes around objects on a broad scale for first calculations, and then, when needed, additional detail is brought into consideration. That’s why when you walk very quickly across a prim surface with lots of holes due to misaligned prims, your avatar might not immediately fall through — but if you walk very slowly, this might actually happen! (in some cases, the reverse might happen). This has mostly to do in the way the physics engine, to minimise calculations, might just use a “rough” bounding box collision calculation to give a preliminary result.
You might see this at work with sculpties. Some first-generation sculpty terrain elements (like rocks and such) had a very strange effect on avatars: they would simply “float” over it, as if the object was not really there, or far larger than in reality. Subsequent generations of sculpties have adequated the underlying physical model more closely to the actual surface of the sculpty, but in some cases, people simply set the sculpty to phantom, and add a regular prim on top of it with invisible faces: this will make the physics engine to forget about doing the math for the sculpties and just use the prim for calculating where the avatar is supposed to be moving.
With meshes, content creators have the option to define exactly where the bounding box is supposed to be. This might be used as an adavantage for, say, very detailed vehicle design: a reasonably “rough” sketch of the car can be uploaded separately of the highly detailed model to be rendered. This allows the physics engine (which runs on the simulator, and thus contributes to server-side lag) to make all the complex calculations for vehicle movement based on a very simple model, while leaving the rendering engines to deal with the complexities of the way the vehicle looks (which just causes client-side lag).
However, very complex prim-based models create an additional challenge, as prims can have holes or are just partially visible (prims inside prims, and so forth). The physics engine has to deal both with each prim individually, but also with the entire object — which is a pain and requires intense computation costs; that’s why LL has limited vehicles to merely 32 prims (each avatar sitting on it counts as one prim, so, the maximum number of usable prims is 31). Meshes will make these calculations much easier — the physics engine is supposed to be fine-tuned to deal with meshes, which is pretty much what every videogame uses 🙂
But even things that are not vehicles will certainly benefit from meshes. Consider a typical complex building: lots of prims are used to provide detail. Each prim is a solid with N faces, but only a few of those faces are visible. The remaining might be partially stuck inside other prims (the “walls”) and we expect them to be “invisible”. Yes, invisible to the user — but not to the rendering engine: for the SL Viewer, those “hidden prims” still consume precious triangles which have all to be accounted for — and then discarded because they’re not visible. Just because they’re not visible doesn’t mean that the rendering engine doesn’t see them! Rather the contrary: it takes more time to render something which is not visible to the user, because more calculations have to be applied to it to assert its visibility. This sounds to work against common sense, but it’s how it works… with an advantage, though. The advanced occlusion techniques of the recent versions of the SL Viewer deal with hidden objects much better (at least, when using opaque textures, that is, textures without alpha channels), and make a huge difference in the way objects are rendered.
The point is that with prims, the renderer has to account for all polygons for all faces, even if most of those faces will be actually hidden. And things become more complex with prim interpenetration: a prim sticking out of another prim has partially occluded triangles which have to be calculated separately.
Finally, even a cube that is sticking out of another prim and just has some of the faces visible will have textures for all faces (all needing to be downloaded separately). A common trick used by some content creators is to drop an invisible texture on the non-visible faces — that way, less textures are downloaded, and in theory, this should improve rendering time. I have my doubts about it, because the most commonly used “invisible texture” is actually a full-alpha texture, which will break occlusion and thus require far more rendering computation in order to be displayed — only to be dropped by the rendering pipeline, since that face is occluded. I really haven’t tried this out recently — at least, not since LL has introduced a new LSL parameter for invisible faces and adopted a “standard” invisible texture, which might not be a texture at all, but just a flag for the renderer to say “ignore this face, it won’t be displayed ever”. If that’s the case — and if a significant amount of content creators actually take the time to drop this “special texture” on all faces that will never be displayed — then, yes, this will improve the rendering time. I seriously suspect this not to be the case, though; content creators ought to get better results by painting the non-visible faces with a simple 32×32 “all white” texture instead. But… how many do make their buildings like that? Even professional 3D content creators often “forget” to paint the non-visible faces, they just apply the same texture — at full resolution and often with alpha channels — to all faces, no matter if they will be shown or not.
Meshes change all this. A meshed object in theory has just two conceptual “faces”: inside and outside. Of course, complex objects have multiple meshes and sub-meshes, but each, at least, has “nothing” inside — it’s just “outside” for all purposes. This will reduce rendering time dramatically. Of course, occlusion calculation will always be needed, to deal with objects moving in front of each other (and nothing prevents you to “stick” meshes inside other meshes or other prims!), but I can imagine that a lot of triangles will be saved that way. And I really mean a lot.
Consider a simple scenario. As said, a cube has 12 triangles. An object made of 8 cubes (i.e. a cube made of cubes) will have 96 triangles for the rendering engine to deal with — but the “outside” only has half of that, i.e. just 48 triangles. The “inside” triangles which will always be hidden are still going to be sent to the rendering pipeline, even though they will never be displayed at all. SO you’re wasting triangles and wasting computing time when rendering that object. A mesh would only need those 48 triangles (well, actually, it would use even less, since you’d just need to have a bigger cube — meshes can be at least 64 x 64 x 64 metres big), thus saving half the rendering time. You can easily see how this adds up — a 3 x 3 x 3 cube made from 27 prims stuck together would have 324 triangles, of which only 108 would be visible (just a third!). As objects get more and more complex, you can start to see how most of the triangles used by a prim-based object are all hidden and never displayed, even though they need to be calculated by the rendering engine! And this grows exponentially…
This, I think, is an area where meshes will have a huge impact over equivalent prim-based design. The more complex the object, the more likely it’s going to be way, way less costly to render it if it’s a mesh. At some point, the cost of sending those extra vortex data will compensate far more the additional rendering costs required by prim-based objects. Thus, the notion of “prim equivalents”, which will be based on the amount of data required to be sent will probably just reflect bandwidth costs, but, for meshes with a high number of “prim equivalents”, the actual rendering cost will be far lower than for the equivalent number of prims. This, at least, is what LL is expecting…
Extreme cases are, of course, avatar attachments like hair. In order to “simulate” the richness of real hair, designers have no other way but to get 100-250 heavily-tortured prims, all intersecting and interpenetrating each other, often mixing sculpted hair with flexiprims to achieve better, more realistic results — and that they certainly achieve! Even though the texture count is usually low (most designers I’ve bought from use 2-6 textures, at most; they just get cleverly applied), the sheer amount of triangles — most of them never visible — coming from all those tortured torii and rings have a huge impact on the rendering cost. Now all that can be replaced by a relatively sophisticated hair mesh, which can replicate much more closely the way hair is shaped and moves, and save all that massive amount of triangles. Perhaps with as little as 1000-5000 triangles you can get better results than with 250 heavily tortured prims — which can have, say, 50,000-100,000 triangles! (As a comparison, the whole SL avatar mesh just has merely 7,500 triangles, and, even so, it’s a considerable improvement over many popular games)
And finally we have textures… what has impressed me most on all those easily-downloadable Google 3D Warehouse models is how few textures they use. The trick, of course, is called UV mapping: you can “wrap” reasonably-detailed textures around the whole mesh, and “paint” the mesh directly with all details you wish, and save it to a “wrappable texture” which gets uploaded. This is pretty much what fashion creators (even amateur ones!) have been doing all the time using the clothing templates (which are simply UV maps of the avatar meshes). The advantage, of course, is that meshes (like sculpties, too) will consume far less textures than the equivalent amount of prims.
In terms of bandwidth costs, this is easily a huge advantage, which might more than compensate the additional bandwidth costs for downloading a complex mesh instead of a certain number of prims. But even rendering might be easier: applying textures to tortured prims is costly, too, and you can notice that when using the “planar” setting for textures on tortured torii or rings; even visually, it takes a bit more time for the texture to be applied! Now applying textures to very complex meshes should also take some time, it’s definitely not a walk in the park, but the good news is that your graphics card is supposed to know how to do that in hardware… and even be able to apply all sorts of special effects on top of it, too.
So this is the theory. In general, I believe that a mesh-only rendering of a scene will be way faster than the equivalent rendering of a prim-only scene. It will have far, far less triangles. It might take a bit longer to download all the models, but, on the other hand, it will use far less textures, and they will be applied faster anyway. Moving on top of those meshed objects will also be easier on the physics system, and meshed vehicles should respond better (and faster) while also look much nicer. This is what I expect to happen based on theory. In practice, of course… we don’t know yet 🙂 I’ve tried to walk in the “Mesh City” sim on the Aditi grid, and it certainly took a long, long time to load. But… there were also a lot of avatars around, and Aditi, well, is just a preview grid, running on older (and slower) hardware. It’s not supposed to be able to handle huge loads of users anyway. So how fair is the comparison?
Right now, there is really just one way to try it out: create a lot of models using heavily-tortured prims and the equivalent using meshes (there are some applications to convert between both) and experiment the differences 🙂 I’d be certainly interested to see how well they fare.
Notice, however, one technical caveat. Linden Lab is not going to port meshes for the “old” SL 1.23 viewer codebase: this is a 2.X development only, and will remain so. This means that adoption might be slower than LL might expect. The good news is that several third-party viewers are going to switch over to the 2.X codebase, while changing the UI to be more pleasing (that is, looking more like the 1.X UI). Of course this means some development time; Imprudence, which is currently showing off some early versions of version 1.4, after stabilising and releasing 1.3.0, has just planned to switch over to the 2.X codebase with version 1.5. Kirstens Viewer is currently the only third-party viewer fully supporting the 2.X codebase. We’ll have to see over time if the extra features of the 2.X codebase — Media-on-a-prim, alpha & tattoo layers for avatars, outfit support, meshes, Display Names — will be enough to convince third-party viewer developers to switch over to the 2.X codebase and tweak the UI (since it’s clear that Linden Lab will not change the UI much except for some minor details).
All in all, these are exciting days for Second Life, and I believe that the final barrier for massive adoption by content creators (not for the mainstream public!) has finally been lifted. For users, it just means far better and more realistic content, which might even relieve lag problems, and a Second Life that will look completely different in a few months — we’ll all be laughing at how ugly it looked in the “olden days” of 2010…