animats

Sinespace has integrated Archimatix for in-world building. It's an intermediate level between working with prims and working with raw meshes. It's fast - almost like Fortnite building, but for real. SL needs something with that level of fluidity. Maybe in-world SketchUp. One way to do that would be to integrate SketchUp into the viewer, so that it draws into the SL view. But the editing isn't shown in world. Other users just see a big "Editing Object" sign or a cloud of dust or something until the edit is saved. Then it uploads and appears in world. Like "Editing Appearance" or playing animations locally.

Please don't feed the trolls. Some of us here are trying to discuss the problem and find solutions. I'd like to see concurrency increasing slightly, rather than being flat or declining. Even a small increase would turn the mindset around.

Got the party having problems to re-rez their prefab building while I watched. It first rezzes as a big ground prim, which you position where you want it. Then you give it the go command and the building assembles atop the ground prim. But the assembled building is bigger than its ground prim. The roof of the building has an overhang, reaching into the next parcel. So when the neighbors cleared their parcel to prepare for a building project, the entire building disappeared, leading to much confusion and acrimony. This was a bad job by the prefab builder. They provided an alignment guide prim and it was wrong. The end user used the alignment guide properly and still got into trouble.

That's not really LL's fault - all the new VR worlds have tiny usage. Even Facebook Spaces is not doing well. If Facebook can't make this work, it's probably not happening. VRChat briefly looked like a success. Briefly. They're on Steam, so there are stats for them that come from Valve, not VRChat, and can probably be trusted. VR Chat usage. Peaked last holiday season. Far smaller than SL. Here's Sansar's concurrent user count, into August 2018: Sansar concurrent users. Yes, that's 10, as in 10 concurrent users. All that effort, staff, servers, to serve 10 users. SL still has 30,000 to 40,000 concurrent users and claims 10,000 signups a day. Most of those signups are probably bots signing up on the web site, but some of them are real. (I'd like to know how many launched a viewer and logged in successfully. LL won't reveal that, but they know it.) Build on the success you've got, instead of chasing a non-market. Put the resources on SL, where there's potential for a payoff. The VR market just is not going anywhere in this cycle. Maybe in some future generation, but not this one. If SL could be juiced up to a consistent 20+ FPS and gave new users something interesting to do, it would start growing again.

Whirley Fizzle found a relevant JIRA: OPEN-143. Thanks, WF. (The JIRA was misfiled under OPEN, and closed without a fix.) The test for encroachment is apparently made using the axis-oriented bounding box of the physics model. For non-rectangular objects, that box will be bigger than the visible object. Sometimes much bigger. See the JIRA for pictures of examples. Using the physics model is inevitable; that's all the simulator knows. The physics model is a union of convex hulls, so it's already been expanded from the actual object boundaries. Then an axis-oriented bounding box is wrapped around that, making it even bigger. Plus, the physics model for a mesh object can be manually generated and may be out of position. So you can't tell by looking at the visible object. There should be a tool for this. You can list all the objects on your parcel from the viewer, and it would help if the ones that are partly outside the parcel were flagged. Users should not have to understand the previous paragraph. (I'm chasing this down because someone, in addition to the business mentioned above, had their building returned and they were very upset for days. I'm trying to figure out exactly what happened and keep it from happening again. It's starting to look like a technical problem, not griefing.)

Maybe we're lucky that LL is so inept at retention. "The Fogg Behavior Model shows that three elements must converge at the same moment for a behavior to occur: Motivation, Ability, and a Prompt. When a behavior does not occur, at least one of those three elements is missing." Reading up on this topic is scary. You can see how Facebook does it. And why Fortnite is so successful. Fogg is a professor at Stanford and runs the "Behavior Design Lab". One of his students started Instagram. Second Life scores low on all three axes. Hard to do, no external motivation, and no prompts. If SL got above the green line, it would suck for most of the people here now. But profits would go up.

Tried this yet?

Yes. For a while, I was downloading academic mesh reduction code and trying it. Some does OK on clean geometry. Much of it blows up on flawed geometry. Some of it has trouble when many edges meet at one vertex, as with the end of a capsule shape. Edge angle based reduction tries too hard to follow fine detail. Quadric mesh reduction tries too hard to follow convexity. Much of the work is for making good looking models that resemble the original in closeup, not for distant models. Models for distant viewing could be done somewhat differently. Maybe something like quadric mesh reduction, but with the simplified mesh outside the original being weighted much less than being inside. Think of it as "filling in the dents". Like a convex hull, but not going that far. At distant range, you can't see small depth variations, so they can be reduced out. But you can see changes in the outline. An extreme mesh reducer for generating low-LOD models needs to make that distinction. That approach would probably work well for animal shapes. Then there's deciding when to fill in a hole. Worst case is a spoked wheel, where the spokes are objects of the mesh. All that spoke detail has to go, preferably replaced by a flat impostor. The medium level of detail for a wheel should be a torus with a flat textured insert. You don't want to go all the way to one flat impostor for the entire wheel, or the wheel disappears on-edge. Convex hulling the wheel, then dent reducing the convex hull to a cylinder, then pasting an impostor on the result would work. But that's a special case. Something more general is needed. As a motorcycle builder I struggle with this. Motorcycles are open frames with lots of holes, difficult to reduce effectively. Detecting a framed hole would help. If a hole is entirely surrounded by a solid, it's a good candidate to be filled in with an impostor face with an alpha channel. That would handle windows in buildings, too. Then you run dent reduction again, which merges wall, window frame, and window, and end up with entire walls becoming one flat face with a generated texture. Somebody must have been down this road. Much work has been done on mesh reduction. These can't be new ideas. But I haven't found any references yet. Useful paper: http://graphics.stanford.edu/courses/cs468-10-fall/LectureSlides/08_Simplification.pdf

That may not be enough. One builder tells me that you can (sometimes?) return objects which are exactly on the edge of a parcel. It's 32-bit floating point. There's roundoff error. A safety margin may be necessary. Someone with control over adjacent parcels of different ownership might want to test this and report back. Good project for a landlord.

(Technical stuff ahead.) The texture management system in the SL viewer has all the right features. It can read only the lower resolution forms of a texture from the progressive JPEG 2000 files the asset server holds. It can store textures in the fast cache at lower resolutions than given. It can load textures into VRAM with or without mip-mapping and at full or reduced resolution. It can pull a texture from VRAM, reduce its resolution, and put it back. All this is done by threads running in parallel with the main rendering thread. It's really quite impressive. The trouble is that its decisions on when to do what are implemented in code spread all through the mechanism. There's no central policy module that can be tuned. Nor are there comments explaining what it's doing and why. Texture policy could be smartened up. For example, the viewer could track how far the avatar moved in the last 5 seconds, and how much it looked around, as a fraction of a sphere. A stationary avatar should get a high-rez view in the direction they're looking, near objects first. A fast moving avatar should get low-rez versions of everything, but as far out as possible, so they can see where they're going. No point in asking for high-rez versions; by the time the texture data gets there, they'll be past it. A stationary avatar that's looking around a lot, shopping or sightseeing, but moving slowly, should get medium-rez data in all directions. If they stop moving or turning, then the objects in view get a higher priority and load full-rez. Shoppers would love that. The LOD system needs to be smart in the same way. How you're moving should affect what LOD gets loaded. Tricks like that are part of how to juice up perceived performance. SL needs to deliver at least 20-30 FPS at all times. Even if it means reducing detail level during overload. The texture system sends messages to LL about its performance, but it's not clear if anyone looks at that data.

How can you tell if any of your prims are outside your parcel, even slightly? If they are, they're vulnerable to being returned. There was an incident yesterday where a large store building suddenly disappeared. Looked like a griefing incident. It wasn't. The owners finally found the problem. They had a large rotating sign on top, part of the building, and during its slow rotation, it protruded into an adjacent parcel. A neighbor was doing some cleanup and accidentally returned the entire building. Another common situation is when you have a big ground prim, and it goes right up to the parcel edge. In urban areas, each parcel often has a prim like that. You don't want a gap, so going right out to the edge is normal. Any way to check if it's outside the line?

I know. You can get mobile access to SL right now that way, but it's expensive.

Ouch. One problem we're running into in this business is that it takes more bandwidth to download assets for local rendering than it does to send high-definition video to the user. The future of this stuff may be rendering on the server.

The reviews at https://www.commonsensemedia.org/website-reviews/second-life/user-reviews are fascinating. Worth reading, even though dated. Many of the negative reviews seem to have been written by the same person. Look for run-on sentences, no paragraph breaks, and many spelling errors and typos. The reviews from kids seem to run "I was addicted to this and it was bad for me" or "too much sex." There are complaints of nudity and sex in General areas. Maybe this was worse back in 2011-2012; I don't see much of that today. I suspect sex has moved to Tinder and Instagram. Not sure how this affects new user retention. "It is the duty of the police to suppress vice to the point that those not seeking it out are unaware of its existence." - Cleveland police chief, around 1900.

Biggest design mistake in SL - no hierarchy, just linksets. Philip Rosedale has admitted he blew it with that one. In most draw-type programs, 2D or 3D, you can group things, then you can group groups, etc. SL doesn't have that. That leads to many headaches everyone who builds in SL knows. As for in-world building tools, Sinespace just raised the bar. They licensed Archimatrix and made it work in-world. Archimatrix in-world in Sinespace. Like SketchUp, but better and in-world. SL needs something like this. Search for other Archimatrix videos; it can do far more than shown here. Good for buildings, furniture, and terrain, but not clothing. New World Notes has a nice writeup. Archimatrix is an intermediate-level editor. You're not down at the polygon level, as with Blender or Maya. But you have more power than SL offers with prim editing.