animats

Exactly. Adding more material layers isn't that complicated. They're just images. Material layers are named items in LLSD, and having more of them is possible within the existing protocols. Older viewers would just ignore the new layers. The video I posted is using PBR rendering. The translation from SL specular to PBR roughness and metallicness isn't right yet, though. Shiny will work a lot better in PBR. The SL rendering system can add diffuse and specular and get all the way to full bright, which is why chrome turns white in bright light. In PBR systems, you never get out more light from a surface than you put in with lights. Still no mirrors, though; that's a different problem. Probably the most useful layer to add is subsurface scattering. This is for materials where light goes a little way into the surface, bounces around a few times, and comes back out nearby. Like skin. This is why skin sort of "glows" in real life. Without subsurface scattering, skin rendering is only adjustable along a range from "dead" to "plastic". Second Life avatars are close enough to photorealistic that this matters. There are about twenty additional PBR layers, but few materials need more than one or two of them. Blender and Maya already know how to create and render all those layers. Changes would be mostly to the viewer UI and the uploader. Probably the best way to do this is to have the uploader understand GLTF / USD format in addition to COLLADA. Blender speaks GLTF. Maya has a GLTF plugin. Everybody seems to be standardizing on that. Open Simulator, though...

I dunno. I gather that some others have significantly more problems with other residents than I do. My contacts with LL Governance have been along the lines of "at this location, this object is partly blocking a road" or "giant griefing object is taking out 9 sims near me." I sometimes report excessively large, rotating, floating, glowing FOR RENT signs. (The biggest landlords seem to have the smallest signs. That may say something.) That's about it. I have a moderate sized non-adult business in Zindra, and most of the parcels are open rez with a 20 minute timeout. I don't have much trouble. I have NPCs running around, and they find visitors and say hello. This gives the impression that someone is watching. Under certain circumstances the NPCs will notify me, but that almost never happens. I have a few NPCs at some GTFO hubs, where they perform much the same function. A light touch is effective. I don't see much need for iron-fisted governance. There are occasional serious problems, and that's what LL's governance unit is for. It's good that they don't get involved with the little stuff. I'd like to see LL offer to move content off mainland to isolated regions made to proprietors of mainland skyboxes. But this should be done by persuasion and incentives if at all possible, rather than by order.

Strawberry Linden should be on the Sunday talk shows explaining how SL governs the Metaverse. Everybody making public pronouncements is assuming that the Metaverse will be very authoritarian and require armies of censors. That's how Roblox and Facebook do it, right? That's not how SL does it, and right now would be a good time to get the word out on that. SL doesn't need that much governance. The governance team is tiny. Why does this work? Space keeps everything from being in the same place. Jerks in SL can only annoy about a hundred meter radius, and SL is the size of Greater London. So it's a hyper-local problem. Just like the real world. Unlike text-type social media, being a jerk in SL doesn't scale. There's no "sharing" or "following" to amplify jerks. Property rights. If you own land in Second Life, you can ban people from it or kick them out. Most of the cool places are private, and the owners will ban people if necessary, usually after talking to them first. Just like clubs in real life. Yes, SL has sex. So what? So does the real world. There are General areas, which are teen-safe, Moderate areas, where you can do sexual stuff on your own property, and Adult areas, which are quite permissive. Even so, people tend not to overdo it in public in Adult areas, because there are social norms. Linden Lab acts like a municipal government. Their job is mostly to keep the infrastructure running. There's even a Linden Department of Public Works. They don't try to micro-manage the world. They don't intervene in resident disputes. This hands-off attitude keeps operating costs down. You can't hurt an avatar or damage the property of others. So that's just not a problem. It's possible to litter by leaving objects around in some areas. Those are quickly cleaned up, often automatically. Second Life really is a virtual world, not a game. It has landlords, tenants, property rights, property taxes, evictions, neighbor problems, noise problems, littering problems, and zoning issues. Just like the real world. They get resolved, more or less. Just like the real world. It would be good for SL's image to get this out there.

Probably not. My code is all in Rust, and the internal architecture is completely different. The LL viewer is in C++, mostly single-thread, object-oriented, with a homebrew "coroutine" structure, what would be called "async" today. The underlying world object is the prim, with sculpts and meshes bolted on later. My code is 100% Rust, multi-thread, data-oriented, and uses interprocess channels rather than "async". The underlying world object is a mesh, with prims and sculpts translated to meshes early in processing. Trying to make these two incompatible systems connect would be a big job on the C++ side. I talk to the Firestorm and Catzip developers regularly, but we don't see bolting these things together as feasible. LL tried to do something like what I'm doing with asset loading some years back. It's in a dead project viewer from the "Project Interesting" era. They bolted on a priority queue from Boost, which was the right idea. But they didn't finish the job. The graphics Lindens would like to go to Vulkan and PBR, but that effort has not been funded. So, much of what I've done has been considered by LL, but not successfully executed. It's up to LL to set their own priorities and level of effort. As customers, we can judge them by their results. I'm interested in this partly to find out how to build a good metaverse client, using SL and Open Simulator as testbeds. Both John Carmack (Doom, Oculus) and Tim Sweeny (Epic, Fortnite) have written that this has many unsolved problems. So it's a good project to work on. I'm a computer scientist by training, so I work on unsolved problems.

There are many small shops in SL which have an unused second floor. A service where people could rent those out short term without having to deal with the tenants directly might be useful and fun. Get more people their first home in SL, even if it's a garret under the eaves. Some furniture, a light or two, maybe a hot plate, and you have your first home in SL. This is above a store at a busy GTFO port. A little work, and it can look like this.

We need a 30 second delay on the LSL calls for ejection. Yesterday, I flew from the northern tip of Satori to Heterocera via Bellessaria. 12 threads from security orbs. 3 covenant-violating ones over Belli. The worst problem was someone who had a mega-prim 256x256x1 surround with pictures of clouds, solid. Didn't realize it was an obstacle, hit that and got stuck. Suggested design feature for security orbs: check the horizontal velocity of the avatar. If they will be out of your area within 10-30 seconds, don't bother them.

Agreed. Nor do I have any major plans in that direction. I'm just addressing the performance issues. Mobile is tough. SL on the small screen is just too small. The amount of compute and network bandwidth required is high. You'd need a really high end data plan and a high end phone. SL with cloud rendering is quite feasible now, but you'd be paying maybe $30 a month for server time. And the UI is totally unsuited to mobile. VR is tough. SL movement in VR would make people nauseous. This is a generic problem with VR in big worlds. VR works best in a very constrained space, like VRChat or Beat Saber.

Average age of a Roblox user is age 13. They have to censor hard to keep the parents happy.

Why is some landlord doing this on a large scale? If you have enough of those things to fill a region, you can rent your own isolated region for this sort of thing. Thinking back, the ones in the picture I posted appeared when new regions were unavailable because the old Linden Lab data center was full and the transition to AWS hadn't happened yet. Now that new region sales are working again, there's no excuse for this sort of thing. Does anyone have a "move build to another location" tool that works?

Considering that the surface area of the human body is around 2 square meters, something has gone horribly wrong if the clothing area exceeds 1000 square meters.

Maybe. Second Life is potentially more mainstream now than it has been in the past. Matthew Ball, the venture capitalist, pointed this out in his series of metaverse essays. Because of the COVID epidemic, some form of remote presence is the new normal. The stigma of using a virtual world is gone.

9500 of them probably would be minimum-wage censors. Roblox has about 4000 censors, outsourced to some staffing company in India, and a few hundred staff in California making the thing go.

So what? The stated position should be "It's a virtual world that mimics the real world. Of course it has sex". (Roblox won't even let users hold hands. The word "gay" is banned in Roblox.) Facebook is very evasive about the number of users that Facebook Spaces had, or Facebook Horizon has. It may be a very small number.

https://www.bbc.com/news/technology-59180273 They interviewed Anya Kanevsky, VP of product management at Linden Lab.

There's formal training available on game user interface design. https://gdconf.com/masterclass/psychology-game-ux "Experiencing a game happens in the player's mind. This is why understanding the human brain (especially its limitations) while it is perceiving and interacting with a game is paramount to accomplish faster and more efficiently your developers' goals. This workshop proposes to delve into how the human brain works in terms of perception, attention, and memory (critical elements for usability), and offers insights on human motivation, emotion, and gameflow (critical elements for engaging games). Based on these elements, the workshop proposes a UX framework and UX guidelines during the different game development stages." The instructor has a PhD in psychology, was in charge of the user interface for Fortnite, and has published two books on the subject. So this is someone who knows what works. Perhaps Linden Lab could send someone to take this online course.

Microsoft's "metaverse" is out. Legless avatars again. SL should use this as a marketing point. "Our avatars have legs!"

I've thought about viewer cooperation to boost performance, but it has griefing problems. Never trust the client. There are also terms of service problems. An impostor server, to create the illusion of very large draw distance, is an option. This would store pictures of entire regions. The TOS allows you to take pictures of SL and redistribute them. Each region would have pictures from at least 8 horizontal directions, plus straight down. Beyond draw distance, you'd be shown pictures of adjacent regions, positioned like billboards at the edge of the region. If you're flying, you'd see mostly the straight down images, like flying over a map. Distant images would be blurred a bit, as if there was a bit of haze. This is roughly what Google Earth and GTA-type games do to show you a big world in 3D. With that, users would have more of a sense of place. If there are mountains to the north, you'd be able to see them, and have a sense of direction. When boating, you'd be able to see distant shorelines. When flying, you'd be able to see distant terrain and airport runways, as if you were flying over the map. This takes a few tricks to deal with SL content. The picture-taker would only cover maybe the first 128m above ground, so as not to show sky junk for miles around. The downward pictures would be taken from a height just above the highest object with a ground connection. It would be like "terrain view" in Google Maps, vs. "map view". The pictures would be taken by a bot that photographs the world once a week or so. Mainland only, plus some of the larger multi-sim regions. For a single region, it's unnecessary, of course. This is just a concept for now. I might take some pictures of New Babbage's 14 sims as a demo. A real version would require LL support, or support from other large Open Simulator grids. I used to have a little "impostor garden" in Vallone, where visitors could compare 3D objects and impostors. From 20m away, the impostors looked pretty good. For this, I'm talking about impostors of objects at least 100m away. Here's GTA V: Use of distant impostors in GTA V. Second Life should look this good. This is something LL could do. It' s not that difficult. You get a huge improvement in visual quality for a low investment. It would show off that SL is a really big world, unlike those dinky Facebook worlds.

If only that worked for big, ugly, low-altitude skydomes. Hundreds of objects to derender to make these go away. And they block the sun.

Inkscape and Pinta are options. Inkscape is more for doing line art, text, etc. Pinta is more like a paint program. I used to use Pinta but switched to GIMP. There's still Photoshop Elements, which is a $100 one-time purchase.

That may not mean "jobs" as an income source, but just tasks to do. If you spend any time at the new user areas, you find that the two big questions are "What do I do now?", and "How do I fix this &$*@! clothing problem.". One of the helpers at Caledon, who tends to sit on the benches near the entrance, says that many new users think he's a quest giver. LL has tried, with things like Linden Realms, but they're not that interesting. Part of the problem is that many of the interesting things to do require skills users won't' have on day one. For example, sending users on a quest across mainland using the Drivers of SL HUD, which gives turn by turn directions. That HUD allows for making stops, and doing various tasks at stops. So it's really a full quest system. But there are so many things that can go wrong on a road trip in SL that it would be tough on new users. And all the stuff of attaching a HUD and rezzing a vehicle is a pain. With a grid-wide experience, though, it could be set up so that the new user just walks through a portal to start the quest.

That's what makes Unreal Engine work. Vast amounts of prep and optimization during level building. If you can never see area A from area B, you never need to draw A when in B. Or even load it. That kind of thing.

Roblox has just developed new technology to make clothing Just Work. In the new Roblox system, the clothing is automatically adapted to fit the avatar. This is very new, and still in test. Next generation of Roblox clothing on new-style avatars. It's not just blocks any more. Their in-house designers like a somewhat anime style. That's not built into the system. Creators can create and sell third-party clothing. (Roblox has an average user age of 13, remember. Clothing has to have more coverage over there.) So, it can be done, and has been done.

That's not how this works. That's an illusion. The viewer is in a race with the user to load content before the user gets close enough to see through the illusion. High-resolution textures are constantly being loaded as the camera moves around, and distant textures are being dropped to lower resolution to keep the frame rate up. There's a lot going on behind the scenes to create the illusion that nothing is happening. Pay no attention to the man behind the curtain. Here's another example, from an earlier, lower performance version of the system. This shows what it looks like when textures are not in local cache. This is a tour of a shopping event. Booth after booth of high-detail objects. You'll see some small or distant grey objects that haven't loaded yet, and some objects with fuzzy, low detail textures. As the camera gets close, the grey objects turn to textures, and fuzzy textures go to higher resolution. You never see a fuzzy texture in close-up for more than a second or two. The shopping experience improves. You can see the merchandise. Next problem is getting rid of grey. What I'd like to do there is have a per-region list of objects, faces, and average colors. Download that and use it as the initial color for each object. Here's a test of what that would look like. Mono-color mode. No textures, just colors. The object color is simply the texture reduced to 1x1 size, which is a single color. The plan is to show something like this when you first enter a new area for which textures are not yet available. The amount of data needed to do this is small, and so this info can be cached for a very large number of regions. Texture loading will quickly follow, starting, of course, with the objects occupying the most screen space loaded first. No more annoying, immersion-breaking grey. You can see where you are. You can see where you're going. There is no fundamental obstacle to Second Life / Open Simulator looking like an AAA game title.

This is just the rendering part at this point. Log in and cam. It's a long way from a full viewer. I don't want to get end users too excited about this. Many viewer devs, both inside and outside Linden Lab, know what I'm up to. After a year of work, and some good results, I decided to put out a progress report. This is partly in response to recent comments about excessively large textures. Those are not a real problem if you don't load all those pixels until you really need them. If you get close enough to a 2048x2048 texture to fill your screen, it will get loaded, but not otherwise. Some of what I've done here could be done in the LL or Firestorm viewers. They have a texture loading priority system, left over from Project Interesting, but it was never finished. All this applies to non-avatar objects. Avatars have their own rendering problems, and I have not looked hard at those yet.

I've mentioned occasionally that I'm working on a new viewer. Here's some video from an early test version. Second Life at full detail. This is what Second Life and Open Simulator should look like. No more standing in front of a blurry object and waiting for it to load. Waiting, and waiting. And wondering if it's worth the wait. This changes the whole SL experience, for the better. Now Second Life looks like an AAA game. Second Life content does not have too much detail. It just needs a more effective graphics system to display it. What's going on here? This is an all-new viewer, with no Linden Lab code. It's written in Rust, and uses Vulkan for graphics. It has physically-based rendering. It's multi-threaded. One CPU is just refreshing the screen, at 50 to 60 FPS here. The other CPUs are making changes to the scene as the camera moves. All those high-detail textures are being loaded from cache just before the camera gets close enough to see them. If everything is in cache, this viewer can stay ahead of camera movement, even for very high detail content like this. If the content has to come from the server, the objects that cover the most screen area are always loaded first. So what's in front of you is never blurry for more than a very brief period. All this is very experimental. This is just the rendering part of the viewer. There's no user interface other than moving the camera. All this can do is look. I'm working through the hard problems of building a high-detail metaverse here. The underlying technology is cutting-edge - the Rust programming language, Vulkan, WGPU for cross-platform graphics, and Rend3 to make WGPU usable. The lower levels libraries are not yet stable or complete. (For example, WGPU doesn't implement rigged mesh yet, so there are no avatars shown.) I'm doing this to see what's possible medium-term, not to produce a new SL viewer in the near term. Linden Lab tried to do something like this once, as part of Project Interesting. But it was a tough retrofit for the old viewer code, and they were not successful.