animats

This is something new - DeepBump. It's a free Blender add-on from Hugo Tini in Switzerland which takes in images and generates plausible normals using machine learning. It's smart about this; it's doing this from training sets, not just converting color to depth. Works great on easy stuff like bricks. So I tried it on something harder, one of my NPCs. Left, with DeepBump-generated normals on the body. Right, no normals. Only the clothing has been processed, not the face and hands. Look at the cargo pockets on the pants and the sleeve seam at the shoulder. The clothing is better defined. DeepBump recognizes seams and wrinkles, and gives them depth. Don't need the model in Blender for this, just the texture. I exported the texture from SL, brought the texture into Blender, mapped it onto one face of a cube, applied DeepBump to that material, exported the resulting image to a .png file, uploaded it into SL, and applied it to the appropriate face of the model. Default settings, no manual tweaking. This could be a useful tool for retrofitting normals into older SL content. The main texture wasn't changed; there's just an additional normal texture. Normals cost zero LI, so it's useful for animesh models such as this one, where huge triangle count means huge land impact and you can't afford to model every seam.

I need a .bvh file which just has all the neutral positions for a bento skeleton. Pose stance would be fine. I just need to be able to reset the extra bento joints after a bento anim has terminated and I need to run a non-bento anim. My NPCs are slightly lopsided after they shift from running (bento) to some of the non bento standing anims.

It looks like there is a state machine inside, fighting to get out. Login, connection to neighbor, and teleports all follow a pattern. So here's an attempt to express this as a state machine, to understand the constraints on what can happen when. A region connection state machine (first draft) IDLE state - no connection DISCOVERY state - finding out or being told about a region to connect to User makes login request to login server, or Home region server sends EnableSimulator to viewer to display a nearby region, or Home region server sends TeleportFinish to viewer. (I think) CONNECTING state - actually making the connection to the new region. State entry requires knowing requires knowing IP, and port of new region. Seed capability comes in via EstablishAgentCommunication Set up UDP circuit. Do RegionHandshake and reply. Fetch capabilities. Start event poller. CAMERA_AIMING state - agreeing on the viewpoint. Viewer and server have to agree on where the camera is. This is the messy part where, for login and teleport we need the ObjectUpdate for the avatar so the viewer calculate the camera location, but can't get it without sending a dummy location first in an AgentUpdate to start object update sending. This state can be skipped for neighbor connections, because the camera isn't moving. LIVE state - fully connected and operating normally. AgentUpdates going out from the viewer, ObjectUpdates coming in, region live, user interacting and happy. Enjoy SL. FAULT state - something went wrong. Invalid message or timeout in DISCOVERY, CONNECTING, or CAMERA_AIMING state. Log problem, maybe send report, including event sequence that got us here, to a server. For login, go back to login page. For teleport, teleport has failed, try to continue from old location. For neighbor region connection, display a region down hole in the ground. Discussion This almost fits what's happening. Almost. There are are two known ordering problems: The seed capability comes in later than we'd like viewer side. It would be nice to have the seed capability before the first thing that needs an asset. That would be the terrain textures in the RegionHandshake. But RegionHandshake must precede EstablishAgentCommunication (at least for SL; the Other Simulator sends it earlier). Some object updates and terrain info come in before we have a seed capability. So asset requests have to held until the region transitions to LIVE state. Not too bad. Timing of RegionHandshakeReply is touchy. Deliberately delaying RegionHandshakeReply by 2 seconds seems to prevent login interest list problems. This suggests it should be sent later in the sequence. Comments on how that works server side would be helpful. There's an underlying model to all this. I think. What have I missed? Can we fit region crossings into this model?

Ouch. Need to think about the implications of that. With reliable UDP messages, at least you get a few retries. I'm aware that UDP message dropping under overload can occur on both sender and receiver side, and that those are usually repaired by retransmission. But if the event queue drops messages under overload, there's no similar backup. Some messages you never want to drop. If an EnableSimulator is dropped, the viewer has no idea that it hasn't been told about a region, and will never do anything to discover it. That makes me think of those rare situations where you reach the edge of a region, and the other region isn't showing, even though it's up. That was much more common before AWS uplift. I haven't looked at the side of communications that involves group messages and such. Beq Janus is the expert on that and might have something to say. As in RSS? Right, there it's interpreted as "I've seen and processed everything through #117, send me anything from #118 and later." If you lost the TCP poll connection with data in transit, there might be loss. The sender side has to be be careful about the write completion and close status on the TCP connection for this to be airtight. The TCP protocol knows on the write side if there was a clean close with all data delivered, but whether that info makes it through the socket interface is questionable. Or whether that even still works. There's a good chance that info does not make it all the way up through the HTTP and HTTPS protocol stacks, because web servers don't care if they delivered the entire web page. So you probably do need the ability to go back one ID number. Incidentally, on a timed out event poll, SL does not send the documented 502 status; it just closes the connection. (The Other Simulator does send a 502). Timeout occurs around 58 seconds on both SL and the Other Simulator. Since asset sending over UDP is finally dead and removed, UDP traffic isn't that heavy. It's probably appropriate to go more for reliability and worry less about overload.

Exactly. Situations like that probably underlie some fraction of login, teleport, and region crossing failures. When you see those viewer-side, they take the form of waiting for something that didn't show up. "Why" is usually a mystery, although with suitable logging, you can see where things went off the "happy path" and got stuck. I'm glad this is getting attention. Ah. AgentUpdate messages are already being regularly sent to the host region simulator at this point, since that region is already live and the agent is present there. No problem there. What starts object updates from the neighbor region? Sending it an AgentUpdate? If so, that's good, because that can be put off until the region handshake and capability fetch exchanges are out of the way. (The chicken-and-egg problem with the first AgentUpdate seen at login and teleport doesn't apply here; we know where the camera is when connecting to a neighbor region.) Might, might not. What else server side sends an asset UUID to the viewer and wants an asset fetch started before we know the seed capability? Land textures have UUIDs, for example. And they seem to come in before object updates start. I probably should bite the bullet here and be prepared for arbitrary delays in getting seed capabilities and the caps obtained from them. I've seen Firestorm logs with errors in capability fetches, so this isn't a theoretical risk. All of this is much easier if it goes 1) connect up new region and get all info needed for communication, 2) tell it to start sending content. When those overlap, as they do at login and teleport, it's harder. Those are used for something? For a while, I was sending the string "TEST" instead of the proper LLSD message with ID number, and it still worked. Sequentially numbered events showed up. (SL has consistent event ascending numbers from 1; the Other Simulator will sometimes skip a number, and starts from some arbitrary large integer.) The event queue has ordered reliable delivery, which is useful where order matters.

Back to connecting to a region. OK, so I have to do more before I get to find out the seed capability. The headache is that if the viewer sends an AgentUpdate and a RegionHandshakeReply to the new region, it should start getting ObjectUpdate messages. But it can't start processing those fully until it has a seed capability and the neighbor region's capabilities, because it can't start the asset fetches without those. So those have to be deferred until the capabilities are fetched. I wasn't expecting that constraint, and it's a pain, involving a defer queue. Can I avoid getting object updates from the new region before I've received the seed capability? If I have to handle the hard case above, so be it. But do I have to? The way the Other Simulator does this is much cleaner. You do all the communication with the current region before you start talking to the neighbor region. There, you get EstablishAgentCommunication from the current region before doing anything with the neighbor region. (Why does EstablishAgentCommunication even exist, anyway? All it contains is the IP address and port, which was already delivered with EnableSimulator, and the seed capability. Just putting the seed capability in EnableSimulator would have been much simpler. Sending them at different points in the sequence hints that it sent to prevent the viewer from doing something too soon. If so, what? Starting the EventQueueGet poller too early?)

Wet meat in market stall, Port Babbage. Sharpview. Wet meat in market stall, Port Babbage. Firestorm.

The main problem with JPEG 2000 is that the decode process is really slow. (JPEG decoders are either slow and buggy, or expensive to license.) And the way to read part of the file and get a lower rez version is badly designed. But that has nothing to do with VRAM utilization or texture thrashing. Those are separate problems. LL started to address texture loading in "Project Interesting" some years back, and there's an abandoned project viewer where you can see the beginnings of that. Here's my Sharpview tech demo of that problem, solved. It's a speed run through Port Babbage. There isn't enough VRAM to put the whole region in the GPU. Textures are being frantically loaded and unloaded by background threads. If you look closely, you'll see that, especially where the camera approaches and enters "Savory Street Market". Note the sign being blurry, then snapping into focus. Some of the vendors in the stores are blurry at first, then load at higher resolution. It's not perfect, but it's pretty good. (If that transition was a 3/4 second dissolve, like it is in GTA V, you probably wouldn't notice at all. Blink and you'll miss it.) There's no reason the mainstream SL viewers should be stalling for 30 seconds to get some textures upgraded to the needed resolution. That's just a bug. Anyway, no, it's not JPEG 2000. And it's unrelated to ray tracing. The rendering feature I think SL needs is subsurface scattering for skin. This is the effect where light hits skin, bounces around inside, and a bit of red light comes back out. Light goes into skin, comes out somewhere else with a color change. And we humans react "It's alive." Humans are hard-wired to detect this as "alive". Without that, you're stuck where we are now, in the uncanny valley, with a range of choices between "dead" and "plastic". The theory of this is complicated, but it becomes one shader and one more material layer for skins. This layer should have been in the glTF material standard. (It's an extension.) It's in Blender and Unreal Engine. There's realism, and there's "ooh, shiny thing". Both have their uses. People love shiny thing features. Go visit "Materials 1" on the beta grid. So much shiny. Very soon, even shinier, with mirrors! If you saw the '70s disco in test at Rumpus Room 1, you saw how far this can go. Ray tracing is really good for shiny things. But you get a lot more bang for the GPU buck with good normal maps. Enough rendering for one day.

I'm impressed with how well Linden Lab has been able to make the society work. Everybody else, from Meta Horizon to Roblox, has an army of low-wage moderators armed with ban hammers. The Second Life property rights system gives users enough authority to deal with minor problems. There are few ways to annoy people at long range. So SL Governance is a small operation that handles only major problems at a slow pace. This is a remarkable and under-rated achievement.

I want to set up some more NPCs. I have a good scripting system for that, but need more models. I'm looking for generic background characters useful for making a place look busy. Like this. Generic child NPC. Suitable as a background character for fantasy roleplay sims, etc. 22 LI. Generic human background street characters. At least as good a model as the above. Less than 30 LI dressed. Mod or full perm. No scripts needed; I'll do that. Usable LODs, so they don't disappear at distance. Fully rigged and ready to animate. Prefer Bento. Not ripped off from some Disney/Marvel franchise, Game of Thrones, etc. (This excludes a sizable fraction of what's on Marketplace.)

Bad lower LOD model.

Right. A sequence diagram plus a state machine covers that. The trouble is, this system wasn't designed in terms of state machines, and trying to document it that way is difficult. What we see in the code (at least viewer side) is "here is message A, do this", "here is message B, do that", somehow adding up to a protocol. There's no explicit variable that says "we were in state X and are now transitioning to state Y'. There are also places where it's "must have both A and B, in any order, to do X". Event sequence diagrams with comments are a good starting point. We can look at what messages go in and out, and write diagrams accordingly. That doesn't necessarily tell us what the constraints are, but it's a start. Formalism is needed because it's hard to get your head around how something this complicated works. Whoever designed it probably had it all in their head, but two decades of changes later, nobody really does. Sequence diagrams are a concise way to describe what's happening. They don't describe all the possibilities, but just having a clear description of the happy path is a big help. Most of the problems involving login, teleports, and region crossings getting stuck involve one of the players (viewer, servers) waiting for another one of the players to send something. The other player isn't sending it. If you can look at logs and event charts and say "things were on the happy path up to this step, and then stalled", that provides enough info to start work on the problem. This is all about making SL's long-standing, mysterious, and unsolvable problems less mysterious. And perhaps fixing them. I'll have a go at that, starting by putting the diagrams above and their source code in the SL wiki. Edit: Starting to fill this in. See https://wiki.secondlife.com/wiki/Protocol#Protocol_Sequence_Diagrams

I don't know how you find them as customers, but there are thousands of houses in Bellesaria still unfurnished. Every Bellesaria house has a paying premium member,, so that's a market with some money.

Thanks. I'll be trying that soon. Meanwhile, I'm trying to document parts I already have working. Here's initial login: If something above is wrong, please let me know. I'm going to put these charts on a wiki, or Github, or something, for the benefit of TPV developers and others who need such details. (These are drawn using a free tool at "sequencediagram.org", if you want to draw some.) A full set of charts would include: Login (above) Adding a neighbor region (above) Dropping a neighbor region from view. Teleport to distant region, with all-new neighbors Teleport to nearby region which is already a visible neighbor. Region crossing, non-corner. Region crossing, corner, i.e. a double region crossing. You know, all the stuff that gives trouble.

I get that feeling, too I think it's UseCircuitCode or RegionHandshake to the neighbor that's needed, but I'm not sure yet. AgentUpdate messages to the host region were already being sent and do not trigger an EstablishAgentCommunication message from the host region providing the seed capability for the neighbor. Beq Janus and I have been trying to figure this out. Beq produced the event diagram above, after watching what Firestorm was doing. I'd been testing against the Other Simulator, which sends EstablishAgentCommunication immediately following EnableSimulator, without requiring any additional messages from the viewer. This differs from SL simulator behavior. (I'm trying to figure out some way to formalize this with event diagrams like Beq's above, and state machines, like the one for TCP that's in Monty Linden's profile picture.)

Oh, are you setting up a Hussade game?

Or just https://maps.secondlife.com/secondlife/Bay City - Falconmoon/118/90 That other stuff is ad tracking from Google.

Try LlSetKeyframedMotion. You can use that into loop mode, and have it rock the boat gently with no ongoing script activity. This is both more efficient and looks better than doing many moves with llSetRot. Notes: End position for keyframe motion must be the same as the start position for a smooth effect, or it returns to the start position in a sudden jerk. Drift is possible. Once every 10 minutes or so, reset to the starting position. When someone turns on the boat and it goes physical, allow about 2-3 seconds between using keyframed motion and using physics. SL has three motion systems (set pos, keyframe, and physics) which are not interlocked. Switching between modes without some dwell time results in bogus motion.

OK, I get that. Have to send UseCircuitCode and do the full region handshake over UDP to the neighbor to get the EstablishAgentCommunication message from the host region..

More info: There's another chart on that page, simply marked "Related", which shows this: This looks like the procedure by which an EstablishAgentCommunication gets generated. Maybe. This shows the client (viewer) making a UDP circuit connection to the neighbor, and then an EstablishAgentCommunication message being sent from the simulator that has the user's avatar (the "main agent" is the term used in code). Now, why that UDP message to the neighbor simulator should be required, or even useful, is not clear. If that's an actual constraint, then there has to be some server-side inter-server communication by which Neighbor Simulator tells Simulator that Client has talked to it. This is just some random chart that happens to appear on the wiki for the Other Simulator, so I don't want to take this as authoritative. Especially since I know for sure that the Other Simulator does not need for the viewer to send UseCircuitCode before it sends EstablishAgentCommunication.

One of those really obscure technical questions viewer developers sometimes need to know. Background: When logged into Second Life, the viewer is talking to one or more region simulators. It's always talking to the region your avatar is in , and it's usually talking to some nearby regions to see what's over there that needs to be shown on screen. This depends on draw distance. When you first log into Second Life, your viewer starts by talking to the login server. The login server decides if you get to log in, and if you do, it returns enough information to let you talk to your initial region. This includes the region handle (which is just the X,Y location of the region), the IP address and port of the region for UDP messages, and the "seed capability", which is a URL used for requesting more URLs from the region. The "seed capability" URL has a randomly generated field for security reasons and is only good for the duration of the login. That's the beginning of how things get started. On a teleport, there's an event, TeleportFinish, sent over the EventQueueGet HTTP connection, with similar information about the teleport destination region. (Yes, the wiki shows that as a UDP message, but it was moved to the event queue years ago.) So that's how the initial phase of simulator handoff works. Now, once you're connected to a SL region, you need to know about nearby regions so you can see them. So the main simulator your avatar is in sends EnableSimulator events telling you about nearby regions. These contain the region handle, the IP address, and port of the nearby region. For some reason, though, they don't contain the "seed capability" for the new region. So the viewer can't connect to the new region yet. There's probably some historical reason for this. So there's another event, EstablishAgentCommunication, which provides that info. But, in my Sharpview viewer, I'm not getting that message from SL simulators. So Sharpview can't connect to nearby regions. I get EnableSimulator events for all nearby regions, but no EstablishAgentCommunication messages. That's weird, getting one but not the other. EstablishAgentCommunication does show up in messages from the Other Simulator. Sharpview gets the info needed to connect to neighbor regions over there. There's code in the LL viewer to handle this message. It's shown on the SL wiki as coming in with EnableSimulator. So it ought to show up. The message sequence is documented for the Other Simulator. Probably works the same way for SL. Diagram from 2009. Sequence of events for a teleport in the Other Simulator for a region you can see. When a teleport fails, something in the above sequence didn't happen. This shows the process of discovering a neighbor region, making it visible, and then, later, going there via teleport. Note the EstablishAgentCommunication message. I am not receiving that from SL regions in Sharpview. Do I need to send something to get the simulator to send it?

Where's a good in-world store with Senra clothing?

Good job! This makes a lot of sense and will make sense to gamers. If you move the mouse in normal mode, your head should turn as it does now, but the viewpoint should turn, too. So, where your head is looking is where you are looking. Useful limits are about ± 70° in both left-right and up-down directions. Not sure what to do about HUDs. I've been toying with an idea for Sharpview that most HUDs move to a "lapboard" you only see when you look down. Some VR systems work like that. Get clutter off your main screen. Not sure if this is a good idea. Some way to hide less used HUDs would be useful.

Github link: https://github.com/SarahWeiii/CoACD

A bit more progress. Finally, a good convex hull decomposition. 10 hulls. Even if the window is slightly off. This was made by: Create model in Blender. Clean it up until it's a valid manifold. Watertight solid, all normals correct. Blender has a "Manifold" checker that can tell you if your model is watertight, but it doesn't fix it for you. Triangulate. Must be triangles, not polygons. Export to .obj format. ./coacd -i work/house1atriang.obj -o house1atriangphy5b.obj -pm off -md 7 -t 0.02 Takes about 3 seconds. Import new .obj file back into Blender. The program is rather brittle academic software. If you don't triangulate the input, the output is terrible, but you don't get any error messages. The program is supposed to be able to cope with non-manifold geometry, but that feature rounds square corners and messes things up. "-pm off" turns that off. So the theory is coming along, but the code needs some work. I'll try some harder cases soon. I've tried my escalator frame, and it's not bad except for parts that are not a valid manifold. Have to fix those and try again. Probably the most useful form of this for now would be as a Blender plug-in to help make SL physics models. It's not ready to be part of the uploader. Nice to see advances in the technology, though.