animats

Drivers of SL has a weekend long thing twice a year where people camp out in a trailer park after a long drive. Is that it?

Right. If you time out, you have to re-poll with the last ID you received. That's why I suggested that event poller timeout should be server side and should consist of sending a normal LLSD reply with an empty array of events. That unambiguously says everything is fine, no traffic right now. The ID then advances by 1 and both ends stay in sync.

That's a problem with animesh and NPCs. It's possible to do quite a bit. It's not easy, and little about it is user-friendly. Still, the fact that the Zooby crowd has been able to come out with lines of baby clothes shows that it's possible to create a niche market. An alternative is to take some game-type model and turn it into animesh. There seems to have been a purge on Marketplace of animesh from the Star [Wars|Trek|Gate|Craft] universes and the Marvel Overextended Universe. With those gone, there's far less animesh out there. Now, there are plenty of un-rigged 3D human characters for SL. Generic background characters, suitable for populating airports, stores, and such. Unrigged. People put these in stores, but since they can't move, they're not too interesting. There's a good supply of these on Marketplace. But they cannot be animated. I'd like to have more good human models like that, rigged for animation as animesh and not ripped from some game.

That's great news! Those are clear problems to work on. When solved, the remaining problems should be more repeatable, and a big step closer to being fixed. Hm. If you need more checking viewer side for that, just ask. Is this UDP side or event poller? I see sequential numbers from the SL simulators for both. The Other Simulator does sometimes skip sequence numbers. I get a few duplicate UDP messages; not many. I just noticed that I log any ACK that doesn't match an un-ACKed message as a "duplicate ACK", so totally spurious ACKs will be logged as "duplicate". I'll take a look for spurious message numbers coming from the simulator.

Try linking them together and then check the "Animated mesh" box in the Edit menu. Suddenly the clothing and Statue/NPC should jump into alignment, as the "rigged mesh" system turns on. There may still be fit problems, though.

Sample animesh characters. Not for sale. From left to right: Mesh hair, hoodie and shoes, all specifically made for animesh use. Texture leggings. 37 LI. Dress from Marketplace. This is a bad dress for animesh, because it lacks a useful lower LOD and disappears at distance. 48 LI. Basic model. Mesh hair and shoes, texture T-shirt from Robin Wood template. There are texture shoes available with the basic model. 33 LI. Here's the problem with using avatar clothing on animesh. Add a simple cap and halter top to the character at the right above, and the LI jumps to 87. Elaborate outfits result in LIs from 130 to "Parcel Full".

It's possible, but somewhat difficult. First, you need an animesh body. I bought one from Uno Blockke. This is a nude body, generic female junior, with standard SL UVs and with the body texture files. Check the "animesh" check box in the edit menu to turn on animesh mode. The model's LI will increase by 15 when you do this. Starting from this, you can build up an NPC. It's a pain. Animesh do not have "Wear" or "Add" You can add texture clothing to the body. First step is to get the body texture files into Photoshop or GIMP. Now, for texture clothing for which you have the texture files, you can composite the clothing on top of the body. When you upload the texture file you just created and put it on the animesh, the clothing should work. Any texture clothing with standard SL UVs should work. The old free T-shirt templates from Robin Wood will work. Make a T-shirt for practice. It's not too hard to get to the t-shirt and leggings level of texture clothing. Mesh clothing is added by linking it to the animesh. There are no fit adjustments, so it has to fit. Try stuff. If you need an alpha, you'll have to go back to your texture image and erase parts of the image. You need full perm if you're not the creator, or the linking won't work. Most existing mesh clothing has huge LI. For animesh, 666 triangles at Highest LOD = 1 LI. It's a good idea to try random clothing in a big sandbox with plenty of free land capacity. There's a tiny amount of animesh-specific clothing. Meli Imako makes some hair for animesh. There's stuff for Zoobie babies. There's some slave girl sex doll stuff. Not much else. I had some low-complexity clothing custom-made, a hoodie and sneakers. When I got into NPCs, I'd hoped that a market in clothing for animesh would develop. It didn't. Now, to get your NPCs out of a T-pose, you'll need animations, and some LSL program to turn them on and off. There are script systems available for that.

It's routine to report overly blatant FOR SALE signs. After a while, governance makes them disappear. I usually report ones that check off at least three of the above no-nos. Giant FOR SALE columns, glowing, and rotating, can be the biggest ugly thing in view range.

"Gatekeepers" such as Apple will not be allowed to retain that power for much longer. In six months, the European Union's new "gatekeeper" antitrust rules become effective. There will be non-Apple app stores.

Note the LL ad policy rules. Your sign may not glow, flash, rotate, float above ground, or be more than 8 meters high. The big, successful SL landlords all use rather small, unobtrusive for-sale signs.

An "event lost" indicator, for both event poller events and UDP messages, would be a good start. That would distinguish overload-related situations (busy shopping event with many avatars entering and leaving) from other kinds of problems. If there are no missing events, and the fixes mentioned above have been made, but things still reach a "stuck" situation, then there's a well defined problem to look for.

I kind of suspected that, since my first implementation simply sent the string "TEST" instead of the proper LLSD poll request. It still worked. Willing to help there. That's OK. Having a sound communications protocol underneath will reduce the noise level, and make it easier to find the remaining intermittent bugs. I'd like to plug again for the idea that, in the unusual event the protocol has to drop something due to overload, put something in the event stream that tells the viewer that data was lost. Then we can distinguish between overload (as in, we need more capacity somewhere for busy event regions, or something has to be done about the disco with all the material-changing floor tiles), and missing messages (as in, viewer has been waiting for EstablishAgentCommunication for 10 seconds now.). Something like that in the UDP message protocol, should a reliable message be lost, would also be helpful. Silently losing important messages made debugging difficult. This is real progress.

Right. I never see a legit 502 error from Second Life. I handle timeout as described above, which does seem to work. But I have more control of the protocol stack in Sharpview, since "curl" is not involved. So, if this is being overhauled, I'd suggest that sim server side send a 200 (OK) status with the no-events LLSD body given above. That avoids problems with error case handing in Apache, Curl, AWS, VPNs, firewalls, and other not entirely transparent middle boxes.

That's the reverse of what I'm doing in Sharpview. I let the server side time out. Timeout server side is well defined - you get a complete HTTP transaction with some status. Timeout viewer side is a TCP connection abort. If that happens while the server is starting to send something, the server probably won't notice. Certainly not if it goes through Apache. So I wanted to time out server side, and use a 90 second timeout. As usual, I start out by doing what the documentation says to do, then look for problems. Current Sharpview error status handling for the event poller: 200 - normal. Zero length "events" array in LLSD is OK. LLSD parsing errors or missing expected fields are logged. ID must be in sequence and errors are logged, but no action is taken. 404 - end of file. Quit polling. 502 - normal server side timeout per documentation. Poll again. (The Other Simulator sends this). Other 5xx errors - log error, after 3 errors wait 2 secs to avoid excessive retry on server fails, poll again. Never give up as long as region is connected. Connection close - log error, poll again. This seems to be the normal SL behavior on server side timeout. The viewer side HTTPS client is the Rust crate "ureq". "Curl" is not used. I'd suggest is that the server should time out first, and it should send an empty events array with a normal 200 status. that is, <llsd><map><key>events</key><array></array><key>id</key><integer>28</integer></map></llsd> That empty LLSD array <array></array> unambiguously says "everything is fine, no new events right now." So no troublesome HTTP error paths are taken in normal operation. Normal operation stays on the happy path. Existing viewers should accept such a no-events message. This is a once or twice a minute event, if that, so it's low overhead.

It looks like much Game of Thrones stuff has also disappeared. I'm always struggling to find low-LI animesh that aren't from some franchise. I script mostly anonymous background characters - workers, security guards, etc. The franchise purge is making it easier to find useful general-purpose characters.

Not Epic. Epic sells Unreal Engine and Fortnite, not Unity. Unity's pricing policy change is causing great turmoil in game dev right now. Is SL's mobile viewer using Unity?

Plan sounds good. Useful technique from robotics: if you have to put something on a queue and the queue is full, put in a message that says "some messages were dropped". Then, at the receiving end, you can tell the difference between a missing message because of overload, and a missing message because it wasn't sent at all. Those errors have completely different causes, and this tells you where to look.

Hard at work. Some of my NPCs have taken jobs at the Bryant and May match factory in Port Babbage. Hard work and long hours.

From the Tilia terms of service: 10.2. California Users If you have complaints with respect to any aspect of the money transmission activities conducted at this location, you may contact the California Department of Financial Protection and Innovation at its toll-free telephone number, 1-866-275-2677, by e-mail at consumer.services@dbo.ca.gov, or by mail at the Department of Financial Protection and Innovation, Consumer Services, 2101 Arena Boulevard, Sacramento, CA 95834. Tilia is a regulated financial service and is subject to state supervision. It's worth reporting this.

That's a good argument for making the event polling system reliable. Making it reliable won't break existing behavior. Trying to wrap recovery around lost events gets complicated very fast. Oh, joy. Most of the events the event poller deals with are not in the "unreliable/OK to miss" category.

Sharpview uses a 90 second timeout viewer side, so the simulator's server always times out first. Henri has chosen to time out first viewer side. Both will probably work. Same timeout at both ends, though, seems iffy. I wonder if the long timeout I'm using is why I see skipped ID numbers from the Other Simulator, but not SL. I'll take that up with their devs. Sharpview processes the 200 status if LLSD is present, stops on a 404 status per documentation, and retries on any other status. I use the Rust crate "ureq" and make routine HTTP requests. I still have a bypass to deal with that 20 year old SL self-signed SSL root cert which uses an obsolete encryption system for which there is no Rust support. (SSL's ancient root cert expires in 2025; the clock is ticking.) All this seems to work. (How is the SL mobile dev team coming along with this? They're re-implementing, not re-using the C++ code, correct? So they get to face all the legacy issues.) (For less technical readers: SL does well at not crashing, as in "region down". Most of the remaining immersion-breaking problems, from teleport fails to clothing not rezzing, involve the simulator or viewer stalled, waiting for something the other side is never going to send, or that was previously sent and lost. Thus the need for this fussy attention to detail down at the communications protocol level.)

That's what mainland and private sims are for. There are well-run estates - the Chung properties, the Grove, etc., where everything looks good but there is more imagination. Bellessaria is, by design, rather banal. There's a market for that. A big one. If they get away from banal, as with the fantasy regions, nobody knows what to do. Curved walls! Help!

From the DeepBump paper: Bark with generated normals, From left to right, final image, DeepBump generated normals, normals simply generated from depth. Try it on some bark samples. It seems to recognize where the depth is in bark.

Cobblestone texture. DeepBump generated normals on left, no normals on right. It now looks like real, rough cobblestones. A bit rougher than I really wanted here, but I could turn down the "strength" in Blender if I wanted. Now I'm tempted to go around adding normals to everything I have that looks too flat. This is a machine learning system trained on good textures with normals. So it knows about common objects. Bricks, cobblestones, and clothing seams all work well. If you get too far from the training set, it may guess wrong, of course.

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.