animats

Big textures are only a problem because the texture loader in the viewer is too dumb. That was supposed to be fixed as part of Project Interesting, and there are bits of code which clearly try to do something, but they don't work. As I've mentioned before, I've been working on this for my own experimental Rust/Vulkan based viewer, where I can try out advanced approaches without dealing with legacy C++ code. Here's an early test. (This is a long way from being useful to end users.) http://www.animats.com/sl/misc/accessmalltest.mp4 This is simply a video of looking around a fashion shopping event with many high-detail images. You can see textures loading and grey objects becoming textured. There's a lot of texture level of detail swapping going on for distant objects, but most of that isn't visible. Note the absence of blurry objects in close-up. This improves the shopping experience. You can see all the displays. The rules used for texture loading are simply this: Try to load and unload textures to maintain one texture pixel per screen pixel. Texture loading priority is based on screen area involved. Constantly adjust the loading queue as the viewpoint moves. Unless you get close to an object, the system won't load a high-resolution texture. So it doesn't matter if you have 1024 x 1024 or even 2048 x 2048 textures. By the time you get close enough to load such a texture, the object is filling most of the screen and deserves to be loaded. If you never get that close, the detail is not loaded. If you get close enough, you will always get the full texture. Fast. Technical notes: Beq Janus points out that this is not optimal for some cases with texture atlases, but in practice that doesn't seem to come up much. Testing continues. Efficiently adjusting the loading queue on the fly is somewhat difficult technically. Fortunately there's a standard Rust library to do much of the heavy lifting. This reduces the priority change overhead from O(N) to O(log N). The standard C++ priority queue in the STL is useless for this, because you can't change the priority of a queued object. The Boost priority queue, maybe. This works better if you have multiple threads on multiple CPUs working on the problem, so queue updating does not affect the FPS. If you have to do this from the main draw thread, it may reduce frame rate.

That area just lost the Lionheart Mainland Embassy, with its nice four-track railroad station. If anyone wants to build a rail-related facility there, Lionheart is selling it off.

Last week the Linden Lab job openings included a "Head of Product" for Second Life. Today that opening is gone. Is there a new head of product coming onboard?

Roblox is trying to attract an older crowd, according to their SEC S-1 filing. So they need to decide what to do. SL has G, M, and A, of course, and used to have the teen grid. Facebook went for legless avatars, and that was a flop. The NFT worlds aren't getting enough users to need governance,. It's not clear how this plays out.

Roblox has a terms of service update. Roblox's average user age is 13. (Since birth, not first login.) But this seems overkill.

(Probably off topic)

https://www.twitch.tv/videos/1173815818 TCG World. A procedurally generated metaverse. It's a big world with procedurally generated terrain. 800 square kilometers of terrain. You can buy plots, and put stuff there. It's seamless and sharded. Every N users get a new instance of the world, and they all see the same fixed objects, but only the avatars in their shard. So everybody sees 800 square kilometers with maybe 20-100 avatars in their shard. It's built from standard MMO parts; Unity for the client, Photon for the server. Plus an asset server. Each client generates the same terrain using a pseudo-random number generator in sync with all the other clients, so they don't really store much terrain in the client. Of course, it's really all about selling land and NFTs. Like Decentraland, the idea is to have just enough low-cost virtual world to convince the Securities and Exchange Commission you're not selling a blue-sky investment. It is, however, a procedurally generated metaverse, and one that looks reasonably decent visually.

There's surprisingly little off the shelf code inside the SL viewer. It has its own math library. Its own mesh format. Its own networking system. Its own graphics system. Its own menu system. It's more self-contained than most programs.

This. Most of the people in this discussion are experienced SL users. Many are content creators. Some have been deep inside the viewer code and have made improvements. The typical new user, who's played modern games, sees that Second Life is really slow and leaves forever. That's the problem. Is there any other commercial 3D entertainment system as sluggish as Second Life?

You need a "car sit animation", which you can find on Marketplace. Once you've tried one of those, and seen where it puts you, it will be clear how you need to adjust the sit target.

Scripts in Second Life don't just run. They get bundled into objects, which can be rezzed, taken back into inventory, copied, and moved from one sim to another. The state of the script survives all that. It's rather clever, and somewhat different from normal program behavior.

If you want to create content for Second Life, you need to create a COLLADA file. This can be done in Blender or Maya. Instructions start here. Second Life has its own rendering system. It uses OpenGL. It is not based on Unity or Unreal Engine or any other game engine. It's not even close. The source code for the Linden Lab viewer is here. The source code for the Firestorm viewer is here.

That may be the legs of the avatar. A seated avatar still has the same collision outline as a standing one. The usual fix for this is to have a seated animation that offsets the root -1m in Z. Then you offset the seat position in the vehicle by +1m in Z to compensate.

Having re-implemented most of SL's protocols in Rust, protocols are not the problem. There's a fair amount of documentation, and you can look at both the viewer code and Open Simulator. (Here's my re-implementation of Linden Lab Structured Data in Rust if anybody cares.) The main problem is that they're all non-standard. Asset portability is an interesting concept. I previously described how SL no-copy objects could be tied to non-fungible tokens so that you could move objects between SL and other grids. I personally don't want to do that, because most NFT are Make Money Fast schemes, and most NFT content is crap. It's technically possible, though. To users, it would be a vendor system, like CasperVend. You buy an object from a vendor, and it's delivered to you, no-copy, no-mod. You also get an event recorded on a blockchain that says Object A belongs to user B and is currently on grid C. if you want to move it to another grid, you can take it to a transfer portal in-world and send it to yourself on another grid. Objects set up this way would have scripts which check, on rez and once a day or so, if they're authorized for the grid they're currently rezzed on. If not, they send a message to the owner and self-delete. To creators, you have to have a copy of the object in a dropbox on each grid where you allow sales. Users active on more than one grid would need a crypto wallet to track their NFTs. None of this requires LL involvement. It's worth thinking about as major brands get into NFTs. Own a licensed Gucci item in Roblox for about US $800. Impress your shallow friends. We could even have a HUD which allows you to click on other people's stuff and check if it's a properly licensed overpriced copy. It would call out to a blockchain node and check for the record that says A owns B on grid C. There could be orbs in clubs to eject phonies. I'm not personally interested in doing this, not being into branded merchandise. If someone wants to do it, go for it.

Roblox is caching up to SL on fancier graphics. Roblox, current generation graphics. Here's their user interface for avatar developers. Their triangle limits are 10,000 tris per mesh part, and 50,000 tris per avatar. For special events, they may be allowing performers to have more. Note the detailed avatar on stage in the lower right above. Roblox just had their developer conference. Their road map to the metaverse is now clearer.

Their average user age is 13. However, Roblox has adult users. More, in fact, than SL does. I have no idea how they sort that out.

I've been using the GLTF test file set from Khronos for rendering tests. But those are mostly tests of one PBR feature at a time. The real problem SL faces is that nobody else tries to mesh-reduce down to the 10 to 50 triangle range. Other systems usually drop to impostors rather than to ultra-low-poly models. So mesh reduction algorithms aren't designed for that. Most examples are taking 50,000 triangles down to 5,000 triangles, not 500 to 50. That's why a mesh reduction algorithm that degenerates to a rough outline impostor is promising. It will look awful in close up, but might look OK at distance. If we can just get lowest LOD to be a rough outline with the approximately correct low-rez texture on it, we'd be ahead of where we are now. You can get the renderer to apply a bit of blur to low-LOD objects. A blurry but otherwise correct background is visually acceptable. Go look at some AAA title video game, and you'll see a lot of distant blur. Large holes in distant buildings, though, are just not acceptable. So, what I'm saying here is that the mesh reducer in test in a project viewer needs to be brought up to where UE4's mesh reducer is now. Everything I'm talking about here is existing modern video game technology. SL just needs to catch up. LL has some young graphics Lindens who get this stuff. Summary for non-technical users: the goal here is to stop distant buildings having holes and missing walls, and distant cars having missing body panels.

I'm trying to find open source code for that. I've found a paper on extracting silhouettes from mesh, out of the CS department at Harvard. The example used is the bunny, a model which shows up in many academic papers. People used to use the Utah teapot, but that became too much of a cliche. Not sure how robust this model is on messy 2D meshes.

That's about typical. You need timers and recovery to get pathfinding to work at all in difficult situations. It can be done, but not well. Standard SL pathfinding with automatic recovery when stuck. Note the messages in the top window as stall recovery keeps kicking in. When a timer indicates no progress with Pursue, it tries short wanders or short forced moves to try to get unstuck. Built-in pathfinding is awfully dumb about dealing with problems. It's another one of those SL features that got to 80% complete, and then work stopped. Frustration with this led me to develop my own system, different what's shown above. It works better, but the cram job to fit it into 14 or so intercommunicating 64K scripts was a huge pain.

Right. Which is a hassle. "Static obstacle" applies to the entire linkset. Fixing that is what that JIRA is about.

This whole episode illustrates why I developed mobile NPCs, but don't sell them. Someone with land rights has to set up the parcel. Most parcel owners do not know how to do this. So someone who does has to go to their parcel and talk them through the setup process, or become a member of their land group so the setup person can do it. There are too many special cases like this where things go wrong and there are tough problems to figure out. It's too time-consuming for a product. If you want to do this, you need a support organization, like the Virtual Kennel Club's "certified trainers". You need to give classes. You need to check back for the first few days to make sure the NPC is working properly. I have a JIRA filed on how to make setup easier. Accepted one year ago this week. So I mostly sell escalators, which, once installed, Just Work.

If you make something a "static obstacle" it goes into the static navmesh, and you can see it. If the static obstacle system knows about an obstacle, pathfinding can deal with it. Movable obstacles are dealt with dynamically, and that part of the system isn't as good. Static obstacles cut holes in the navmesh, as you can see by viewing the navmesh. They have to touch, and sometimes go a bit into, the walkable surface. Incidentally, any part of a walkable surface steeper than about 65 degrees becomes a static obstacle. So you never walk up vertical surfaces. Pathfinding is composed of two different systems working together. The static navmesh part, and llGetStaticPath is reasonably good, but the movement control and movable obstacle part is less good. It has to work in real time, and really isn't that smart. The higher the script load on the sim, the worse the movement gets. Basically, pathfinding gives objects a heading and speed, which they follow until the next pathfinding update. Under heavy load, there are fewer updates and they tend to bump into things.

Right. It actually does move physical prims. Weird.

Can you get voice to work in Voice Echo Canyon? If you're a premium member, contact support. The whole Vivox system is flaky, but it usually doesn't stay down for long.

Second Life has several different systems for moving objects. There are ones that use the physics system, there's keyframe animation, there's direct positioning (llSetPos, etc.) and there's pathfinding. They're not interlocked. You can only use one system at a time. Allow a second or two between changing from one system to another. llMoveToTarget and llSetTargetOmega belong to different systems. llLookAt and llRotLookAt belong to the same family as llMoveToTarget, and can be used together. llTargetOmega is interesting. It's usually just a visual effect of rotation, done in the viewer. Selecting the object will make it stop rotating for you, but not for other viewers. It's for wheels, windmills, and spinning decorative objects, where you want rotation but don't care about actual position.