Building limitations
For eons builders and designers have begged to Linden Lab to include meshes and get rid of prims once and for all. The reasoning behind it is that many of the most talented architects and designers in SL are familiar with 3D modelling tools that (mostly) work with meshes, and not prims. Mostly…? Yes, because the notion of “prims” (ie. gluing together elementary 3D models to create more complex constructions) was never abandoned on the top 3D modelling tools, including AutoCAD. It’s a different philosophy, not necessarily a “better” one. Meshes vs. prims is pretty much the same discussion that programmers have when claiming that “their” language is better than the others — a discussion that goes at least as far back as the 1960s, and after two generations of programmers, will continue to go on. As one of my old teachers used to say — “ultimately, it will all be compiled into machine code; all computer languages are equal”. He was naturally right; his argument, however, is rarely brought in the fierce discussions on forums proclaiming that Python is better than PHP, or C# better than Java. The language wars will always continue as new ones are invented every day.
In the 3D world, ultimately, we have polygons and pixels. How exactly we arrive at them is less important — if we model polygons out of meshes, or out of glued-together prims. It’s more like that the techniques to create a model are so utterly different, and someone used to mesh-based applications for a decade will look at a prim-based tool and sigh in dispair. But prims are not really “bad”. 15-year-old veterans in AutoCAD build in SL with prims faster than they build mesh-based extruded models in, say, SketchUp. It’s just a question of learning a different technique.
Granted, there are huge differences. Due to the way SL worked (with Havok 1), you couldn’t have “subtractive prims” (the closest we have to that are “invisiprims”, a bug that was turned into a welcome feature). It can be mathematically demonstrated that without subtractive prims you cannot build all types of models that are possible with meshes. Also, polygon count on meshes is far easier to figure out — you have no clue how many polygons are added when you start torturing prims, and even going into wireframe mode will mean you have to count them manually. Meshes, however, can be pretty regular (or not) and you can define in advance how many polygons they should contain. For 3D modellers, specially in the game design world, where typically 1,500 polygons are a limit for a mesh (for performance reasons), SL is too outdated, since it doesn’t allow the same degree of control. Even with sculpties, which are a quite clever approach to “cross the mesh barrier” and allow mesh-like structures with a fixed amount of polygons to be generated.
Before Qarl Linden introduced sculpties, the question seemed to be moot. Although SL’s graphic engine could, in theory, use meshes, it would break almost everything in SL. We have a prim-based economy: we calculate everything around how many prims we use on our land or attach to our avatars. Prims are a good, visual abstraction of the amount of CPU power required to draw an object, and of the storage it takes, and the bandwidth required to download an object (granted, not a perfect system — a cube has less textures than a torus, but a torus requires far more polygons to render). Meshes, on the other hand, would push us to a polygon-based model, which is quite harder to understand and visualise.
Isn’t there a compromise? Oh yes… there is. One that surprisingly — or perhaps not so surprisingly! — is being actively explored by residents offering curious tools that “transform” a prim-based construction into a sculptie:
or this one:
Both solutions are quite clever. Why should residents become masters of Maya (or any other 3D modelling tool; Maya, however, seems to be the best, as it’s the one used by Qarl when he created the sculpties), an external third-party tool, to create items for SL? Let SL’s own 3D modelling tools help residents to create sculpties as well!
Baffling as it sounds, from several residents that I’ve asked, this solution is actually simpler and gives incredibly good results than learning an external tool which works under totally different assumptions.
So… if humble residents are able to create SL-based tools that turn prims into meshes… why can’t Linden Lab do the same?
Imagine the following scenario. A 3D modeller starts to assemble an object by gluing prims together, and using subtraction prims to model them further. At the end, the object is linked, and the Tools menu exhibits a new function: “meshify”. Suddenly a new mesh is created with all polygons from the individual prims. You get one object (not an assembly of individual prims), one mesh (not a simple sculptie), and an UV map to apply one texture to it. From the point of view of storage, well, we know how cleverly Qarl “encoded” mesh information in a simple 32×32 or 64×64 texture — allowing the whole of LL’s asset servers to remain pretty much the same. He would just need to allow 1024×1024 meshes (gosh, a million polygons!…) using the same technique. Sure, we would get a lot of big textures that way. But would it really lag SL more? Not quite… a complex object will have dozens or hundreds of textures to load. A one-million-polygon object would just require two — granted, two large textures! — one for the mesh, one for the UV-mapped texture itself. Also, unlike what happens with complex prim-based objects, you could define an upper limit on how many polygons are actually generated (say, just allow 512×512 textures for the mesh — more than enough for most objects, and you can obviously use more than one mesh when building your creations…). But imagine the potential of this technique: anyone familiar with SL’s building tools would be able to quickly and effectively create meshed objects, with a complexity far beyond what’s possible with sculpties right now.
3D modellers claiming to “need” external tools to develop their meshes would obviously love this model of content creation as well. They would just need to know where their limits are, e.g. how many polygons they’re allowed to play with — and use their external tools to upload the appropriate mesh-texture, just like they do with sculpties today. Everybody would be happy.
Granted, there is a huge disadvantage to this model: once meshified, you lose the individual information on each and every prim. So if you need to rebuild your meshed object from scratch, you wouldn’t be able to. However, SL is so easy to deal with an inventory. Clever builders will just keep a copy of the linked, prim-based object before it gets meshified, and the final mesh-based model as well (that’s, for instance, how both Mango’s tool and SLoft work, you can always keep a copy of the original set of prims used to generate your sculptie).
So we know it’s possible. Even Havok 4 should have no problem dealing with this approach. In fact, although Havok 1 might have had troubles with complex meshes (as opposed to simple prims; and we all know that the physical engine used by Havok 1 did not allow more than 32 prims glued together), but Havok 4 can deal perfectly with meshes.
All it takes is LL’s willingness to implement this building method, not any insanely complex rewriting of the whole engine. It’s fully backwards-compatible. It doesn’t require any changes to the sim software or the backend servers. It merely requires some heavy tweaking of the SL client’s building tools.
And while we’re at it… what about megaprims? We keep hearing reports on how megaprims are “nasty” for the physics engine (specially the ones that cover more than one sim, i.e. that are bigger than 256 x 256m). But people still use them everywhere — they’re so convenient to reduce prim count (and lag!). Sculptied megaprims, for instance, have been successfully employed to create organic-looking caves (since the ground texture doesn’t allow holes…) with an astonishingly improvement on the look and feel of several modern sims. But when a nice resident published a patch to the SL client to allow megaprims to be easily created from the SL client’s building tools, Sl’s reaction was pure paranoia. The whole grid was shut down, a patch to the servers was created in 24 hours, dozens of hours of the operations team were wasted in standing by as the whole grid rebooted with the new server software — all that to prevent new megaprims to be deployed? That’s pure insanity, paranoia, and waste of time. Instead, LL should pull their resources together and fix the slight annoying issues with megaprims. And forget about the megaprim use by griefers: griefers have far better (and way more annoying) ways of getting on our nerves than dropping megaprims on top of us to cage us in.
