animats

Might be able to fake that. When you turn your avatar, or point with mouselook, it seems to happen immediately. Actually, it happens immediately for you, but not for others, because turning is done locally, then sent to the server for rebroadcast to others nearby. If you have two logged in screens side by side, you'll see this. It may be possible to do something similar for linear motion. If you try to move, your avatar would appear to move immediately for you. Others would see the move a bit later. If you make an impossible move, such as walking into a wall, you would hit the wall and bounce back about a tenth of a second later, when the server tells you where your avatar really is. Much of the responsiveness you see in FPS MMOs is faked by such techniques. Their speed of light lag to the data center is no better than SL's. That used to be true. Look at the Destinations Guide today, though. You'll see the busiest regions with 50-100 avatars. They hold up OK. Capacity has improved somewhat. The bottlenecks are mostly viewer side, by the way. I've tested with Sharpview, rendering avatars as boxes. Little lag even at Motown with 100+ avatars. I walked a box avatar through the crowd, moving around other avatars, with no problems. Avatar rendering in the viewer is the bottleneck. Plus several well-known server side performance bugs - slow attachment loading, and server side stalls on avatar entry/exit from regions. Those are getting some Linden Lab attention. Crowds are good for the business. The graphics are good, the movement is a little off. We need better transitions between animations. There are requests for LSL calls to adjust animation speed and transitions. The puppetry project seems to be on hold for now. That ran into some tough problems. Well, yes, if you buy all the top of the line stuff. There are freebies for most weapons. Yes, there are problems. Those problems have solutions and, importantly, can be solved one at a time. SL's architecture isn't that bad.

Now this is what combat in SL can look like. With the coming support for game controllers, discussed at server user group today, it could work much better. Normal gameplay should look that good. We may have to work on how to keep the pew-pew crowd and the get-off-my-lawn crowd apart. That's probably not too hard. Many SL users have no idea where the combat regions are.

More comments on that would be appreciated. I was just implementing event polling in Sharpview, but I don't have multiple regions working yet. So I have no hard data on teleports or region crossings at the message level. So far, my observation has been that I get 100% of SL event polls in serial number order starting with 1 with no numbers missing. That seems to work perfectly. (The Other Simulator sometimes skips event poll sequence numbers. Need to take that up with those devs.) That seems to be also true for UDP packets. I see occasional retransmits, but all reliable UDP messages do show up eventually. I don't think that packet loss or drop is the primary problem. Delays and re-ordering, though... In-order delivery, reliable delivery, no head of line blocking - pick two. It is not possible to have all three. The event poller has the first two, reliable UDP has the last two. Event poller events and UDP messages are not synchronized with each other. So everything that handles messages has to be prepared for the unlikely event that something arrives in a non-usual sequence. If there's network delay or packet loss, out of order arrivals become more likely. I suspect, but have no definitive information, that network effects on teleports and region crossings have more to do with arrival order than packet loss. For teleports and region crossings, more than one region is involved, regions are unsynchronized, and each region has its own message data paths. Those region servers are talking to each other, too. The complicates the situation. I've written before about the race condition at region connection that causes some objects not to be sent to the viewer, an "interest list bug". The problem is that the viewer has to tell the simulator where the camera is before the simulator tells the viewer where the avatar is. This results in a sudden jump in camera position at login and teleport, which seems to be able to mess up what object updates get sent. I discovered that adding a 2-second delay before asking the simulator to start sending objects made that problem disappear. That's not a fix, that's just a demonstration that there's a race condition. A state machine diagram, or diagrams, would be a big help here. Then the code could check for event A coming in while in state B, where that's not an allowed event in that state. This is the kind of problem where you need formalism to get it right. This stuff is intensely boring, but essential to correct operation. It's the sort of thing where it's hard to convince management that considerable formal design effort is required to fix things which "seem like simple bugs". I'm glad it's getting attention.

Those huge ping times are from where in the world? 36 hops? Is AWS having a routing problem, or re-routing around some failure?

More impostor-related experiments. There may be an app for this. Reconstruction of real world terrain using Open Drone Map. 2D images go in, 3D model comes out. Mesh reduced to 3100 triangles in Blender. Area is about a quarter of an SL region. Compare this with the GTA V images above. Creating a low-rez 3D model of distant regions from SL screenshots is the same problem as reducing drone images to models like this one. There's open source software for doing this for drone images. It's easier for SL, because we know exactly where the camera is. This looks promising. Lots of work goes into processing drone imagery. It's a busy field with software being actively developed. Anyone into photogrammetry or drone data reduction? If so, let's talk.

Right. Fixed link in above posting.

That's strange. After "uplift", all servers were at Amazon Web Services data center us-west-2, which is in Oregon, USA. Unless some servers were moved to other locations, ping time for all regions should be roughly similar, and transit time should be calculated from Oregon. Here's an AWS ping time checker. Try this, and check US West / Oregon, and see what your raw network round trip time is. I'm in Northern California on gigabit fiber, and see 40 to 80ms there. See if those numbers are unreasonable.

This is a good point. The programs for running avatars under program control are mostly ancient. And buggy, which is why we get bot pileups at safe hubs. Is there currently maintained software for this?

If you can get them to make their bots sit on something, the sim load goes down. Standing avatars are physical. Sitting avatars have the physics status of what they are sitting on. A few years back, I saw about a dozen avatars appear in my home region in Zindra. Always the same avatars. Turned out someone had set up a gay AFK place in a skybox, with a dozen AFKs and a bot to supervise. No customers, though, so after a month they gave up and left. If it's all bots and no customers, expect something similar to happen.

I've met users who didn't know mainland existed. Perhaps. The WelcomeHub water is sailable. I sailed all around the channels in a Laser One, and got a close look at the tentacles coming out of the water. Only one bridge is too low for a sailboat. I've suggested that the WelcomeHub should have teleport gates to: Something that appeals to the pew-pew crowd. I previously suggested one simple combat sim, one that doesn't have meters or factions or an elaborate backstory you have to learn before shooting people. One of the better amusement parks. I previously suggested Hello Kitty land, but there are others. A basic racetrack sim, one that's not too hard and is forgiving. A busy social area, such as London City. Other notes. The shopping mall needs to be oriented more towards new users. It should only have clothing that fits the new avatars. The Las Vegas area gets few visitors. The marriage chapel and the hotel seem like they ought to support sex, but they don't. I tried the movie theater. That's not a bad idea, but it needs a better, and shorter, movie.

Yet being on a road or water makes SL real estate much more valuable. Corsica from the air. Most of the isolated inland land is abandoned, and has been for years. Near water and roads, there's development. Buildings along roads almost always have a connection to the road.

Parking lots in front of stores with object entry turned off or very short autoreturn. That misses the whole point of having a parking lot at a store. People driving by should be able to park and shop. Otherwise, why have a parking lot at all? Allow a reasonable shopping time, 20-30 minutes. It's a weak SL convention that gas stations have a rez zone. When something happens to your vehicle, you can fix it at the next gas station. There's no enforcement of this, but it's a nice gesture. GTFO hubs are required by GTFO rules to have a rez area, which is good to know when you need a rez zone.

Marine railway. These exist in real life, although they're not common. I have this at my house in Bellesaria. The track retracts into the cradle base and disappears. It's normally retracted, but can extend over Linden land temporarily so I can get the boat up or down the track to the water. This is a nice solution if you're close to water, but don't own water.

Are they just selling sex beds or something? Or is it a brothel? At some point, it's time to move to Zindra. Which isn't really that wild.

It's been discussed before. A place to start might be urban areas where there are already terraforming and land cutting restrictions, such as Bay City and Kama City.

Some progress. Turns out that the input must be subdivided into triangles, not polygons, but the program doesn't check for that. On the right, the original. Center, convex hulls with default settings. On the left, asked for more precision. It tends to shrink holes unless the precision is turned up to max. Then it generates too many hulls. Adjacent hull merging does not seem to be working properly. Tends to round sharp edges and generate unnecessary triangles, which would run up the SL physics cost. The developer is looking into this. It's promising, but it needs a better clean-up phase. Too early to say if this is a viable solution for SL.

Some background. This is prep work for my experimental Sharpview viewer. (New release 0.4.6 is now available. If you want the download password, IM me. It's a tech demo at this point. Move and view in one region only. Avatars draw as blocks. Use a low-value alt.) I'm trying to work through the technical issues of making SL-type metaverses go fast with high detail. I'm trying out various exotic ideas, some too risky for a mainstream viewer. Sharpview is a development platform for that. It's all new code, 100% safe Rust, with an architecture quite different than the C++ viewers. Think of this as R&D work on how to build a metaverse for real. Currently, I draw one full region at High LOD at a steady 60 FPS. This is like running at LOD factor ∞. The Vulkan-based graphics and concurrent rendering are fast enough to handle a full region at full resolution. Textures are sized to be one texture pixel per screen pixel, and constantly loaded and unloaded as needed to maintain that. Priority queuing makes that work smoothly. The annoying problem where it takes 30 seconds to a minute for some texture right in front of you to load does not appear in Sharpview. I can't continue drawing meshes at High LOD once more than one region is drawn. Not without requiring some giant 24GB GPU or something. That's not the right answer, anyway. It's inefficient to use all those resources on distant background objects. We need to save drawing capacity for close-ups of overdressed, or underdressed, avatars. Now, the standard SL viewer solution is the LOD system and the draw distance. The LOD system suffers from too much content with bad lower LODs. The draw distance limit means that you can never see far-away objects. Or even, if you have to reduce the draw distance, objects that are not that far away. Both of these approaches often look bad. I'm trying to come up with something better that will work with current SL / OS content. I've discussed better LOD generators, flat images of distant regions used as sim surrounds, and low-poly 3D models of entire regions. All these things are used in modern games. Some combination of those approaches should be sufficient to pull this off. The hard part for most of this is automation. SL doesn't have an art director. Major game studios have a small army of technical artists who use Unreal Editor and similar tools to clean up game assets created by the creation artists. Polishing of game assets for AAA titles was, until recently, mostly manual, but the level of automation is increasing. I've been watching the advances in technology there to see what can be adapted for SL content. That's why I write about such things as silhouette protection in the Unreal Engine 5 level of detail generator, advances in convex hull decomposition, and related technologies. There are enough people on these forums with game dev backgrounds that it's worth it to discuss this in detail. Some of the criticisms are good. Such as the dislike of blur. Can we do all this at a high enough resolution that blurring is down below screen pixel size? On high end machines, maybe. We may have to cut corners on lower end hardware. So that's how all this fits together.

I have one house in Bellessaria, a beach house I got the first day Bellesaria opened. No desire for more. It's the tiniest Traditional, set up with surfboards, lounges for watching the sunset, and beach house type furniture. My main place is the big workshop/store in Zindra. That's where I usually am. For no good reason, other than having some unused tier, I bought a small, rather nice looking roadside parcel in Corsica. All I have there is a shed with a spare motorcycle, and an NPC to keep an eye on things.

A few years back someone blanked out nine regions of Zindra with something that generated random huge blinking geometry, big enough to reach two regions away. It also played Caramel Dancer. That gave it away; it was possible to find the sound, and then the object. Found ARd, deleted by Governance, user never seen again. Recently, someone stole my moveable furniture. I have some chairs you can push around and rearrange if you want. When no one is around, they return to their normal position. Someone dragged them to a ban line in a nearby region, so they were auto-returned and I got an email. This was annoying, but not serious. If it gets to be a problem, I'll make the scripting more restrictive. My parcels are all open rez with a 20-30 minute timeout. I expect occasional problems, but mostly things clean themselves up with no attention from me. Someone did rez a house once, on top of my stuff. But it was just a new user who saw the "Rez Zone" sign and wanted to try out their purchase. I sent them to one of the big Linden region-sized sandboxes sized for large builds. The NPCs I have running around give the impression that someone is watching. They can email me for certain serious problems. It's been years since I got a email for which I logged in and asked someone "Is there a problem here?" I've never had to ban anyone. Worst case, I subjected them to a sales pitch for some of my less useful products, such as the driveway hose bell that goes "Ding" when you drive over it, and the beach ball that bounces off ban lines. Or I put them on a demo motorcycle and let them ride off into the sunset.

We have a problem. Original model of simple building on right. Generated convex decomposition on left. This isn't good. Three walls and the floor were already convex, and they were subdivided, for no good reason. Bug report submitted.

First try of this convex decomposition program. This is the frame from one of my escalators. (No steps; those are a separate part.) On the right, the original. In the middle, the default reduction to convex hulls. This resulted in 24 hulls. Would be an OK physics model. On the left, forced down to 8 hulls. Except for that bump at the top left, which would get avatars stuck on the escalator, it's fine. 8 was too small. Looks OK so far. Its choices on where to cut are reasonable. Try it yourself. I used the Python 3 version, listed under PyPi here. Creators, please try some of your own models and post the results. Thanks.

Second Life has much trouble with bad physics models. The system for generating them automatically during mesh upload is not that great. It's a hard problem. There's been recent research work on solving that. Google seems to be funding work in the field, partly because they need this for Google Earth. New papers, both from 2022: "CvxNet: Learnable Convex Decomposition". Uses machine learning. Some big names in the author list. Difficult paper to understand. Claims better results than other approaches. "Approximate Convex Decomposition for 3D Meshes with Collision-Aware Concavity and Tree Search" More traditional geometric approach. Not too complicated. Open source code on Github. Looks like there's been considerable progress. The big advance is doing approximate convex decomposition, where it's OK if there's a little overlap between the parts. If you go for exact decomposition, as Havok does, the joints get complicated. For collision purposes, a little overlap is not a problem. The second paper has some useful pictures. The input is a single mesh, and the output is multiple convex (no inward dents) meshes, shown in different colors. Convex meshes are suitable for SL's collision system. (Convex hull intersections are fast to compute. See "GJK algorithm" for the theory. That's what everybody serious, including Havok, uses.) This approach seems to get the classic hard cases right. The Havok decomposition has a hard time with simple cases such as a house with four walls, let alone one with a door and windows. This system seems to do better. Harder cases, with the accuracy turned down. This looks promising. If you turn the accuracy way down, something reasonable still comes out. That's what we need. Of course, these are the author's test cases. Anyone want to build the code and run some models through it? The program takes .obj format, so if you have it in Blender, you can try it with this program. SL viewers that upload content send this info as a "Physics Convex Block". Currently, Havok code in the viewer generates those, but a new approach could be substituted.

Just opened! St. Martha's Lodgings. Desperate for a place to stay? St. Martha's is for you! Located in Port Babbage, just across the tracks from the docks. Food, shelter, and blankets. Convenient to the new match factory, which is hiring.

I can sort of see ways to do this. Suppose we had orthographic images with depth from straight down, and angled down from north, south, east, and west. That's something I could generate with a version of Sharpview. Now we have some 2D images with depth, like aerial photographs. Google Earth puts that kind of data together very well. You can look down into narrow canyons between buildings in Manhattan. The canyon has to be really narrow before they are unable to generate a good side image of the building. Now the trick is to crunch that down into a low-poly 3D model. There's open source photogrammetry software, usually used for making 3D models from drone images, that can do this. The "low-poly" part may be hard. Most of the software for this generates point clouds. We want the faces of buildings to be a very small number of triangles, with the outer edges correctly aligned.

What's striking about all this is that SL, with long draw distances, is putting more rendering work into the distant stuff than the near stuff. If we can somehow get past that, the big world thing will work better. Here's more of how GTA V does it. (I use GTA V as an example because, although 10 years old, it remains a popular big-world game that looks good. Its tricks aren't too complicated to be considered as improvements to SL.) So, an alternative to flat sim surrounds is 3D sim surrounds, like off-sim 3D terrain people add to their islands. Rolling terrain, the easy case. This is one mesh with one texture. There are tools for SL to make sculpts like this. Someone was showing examples like this at SL20B. Urban terrain, the hard case. Vertical surfaces are hard. Those buildings, and those orange cranes at top center, will be hard to do automatically. It matters. Distant hard edges against the sky need to look right. That's how people navigate visually. Ten years ago, this was almost certainly done by hand. Today, we see Google Earth and Microsoft Flight Simulator doing this automatically from aerial imagery and depth info. Anyone know of a tool for this? If we had a library of low-rez SL region models like this, updated once a week or so, the compute load for looking at the big world would come way down. Beyond draw distance, the viewer would switch over to these low-rez models.