animats

The latest thing from the machine learning community is automatic face generation. This person does not exist. Click for a new picture. Something like this could be used for avatar generation. Everyone gets a unique face.

Please come to Server User Group today at noon SLT and beat on the Lindens about fixing pathfinding. Pathfinding wasn't that useful before animesh. Now it has a big use case and we need to get some bugs fixed so our animesh characters can move around.

It's great. But why does everyone from SL have pointy ears?

We could lobby Twitch.tv to allow video of SL. At least in General areas. Twitch is scared of sex and does not allow videos from SL for that reason. Not being on Twitch means you're invisible to many users. Look at the list of prohibited games. All the others are all sex, all the time. SL doesn't belong on that list.

That is a nasty bug. Permanently disabling scripts is something the system should never do. Stop running them in a no-script zone, sure, but disabling them permanently? No. And this has been broken for two years?

They do. Turn on pathfinding in a prim and you're instantly at 15 LI. Turning on animesh also has a 15 LI penalty, but they don't add. I'm more or less OK with the animesh charges. The main problem I have with the animesh models I've bought is that they don't have enough triangles at the lower levels of detail. I have a Deadpool model that disappears at Medium LOD. Arguably, the mesh LI cost (1 LI per 666.666 triangles) should not add to the animesh/pathfinding penalty. They use different resources. Animesh uses viewer time. Pathfinding uses server time. Mesh uses network time and GPU space and time. I'd argue for something like LI = max(animesh_penalty, pathfinding_penalty, triangle_penalty) so an animesh character gets 10,000 triangles (666.666*15) before the cost goes up. This would encourage creators to design 10,000 triangle animesh. Then 5000 at medium LOD, 2500 at low LOD, 1250 at lowest LOD. Which is good enough for most NPCs. You can convert mesh avis to animesh and put standard clothing on them, but they're going to come in around 70-120 LI. Mesh, but not animesh. Hoodlum Hill's static background characters, all in one place. A good set for creators to look at closely. Most of these are around 2000-3000 tris. One is 18,000 tris, and it's not the best looking or most detailed character there. It's the woman in red in back. 1 LI, because the lowest LOD has one triangle. Something should be done to discourage that trick. In comparison, the man in the brown jacket is 5 LI, but only 1966 tris. But it has a reasonable number of triangles at lowest LOD. Incidentally, all of these characters look badly distorted at lowest LOD. They all look like the junk the viewer's uploader generates. Creators, at least use the decimator in Blender. It's much better than the one in the uploader. The reduction factor for each LOD needs a look. Animesh is using 2, which is more generous than regular mesh. Regular mesh has a higher value built into the uploader, which encourages too-small low LODs. Somewhere between those values.... Maybe 3?

What's happening? I have Firestorm 6.x on Ubuntu 16.04 LTS. It's been behaving pretty well, and I'm using animesh, pathfinding, and doing lots of fast region crossings on vehicles. The only viewer side problem I've been seeing is that the day cycle for EEP regions is out of sync, because Firestorm doesn't understand EEP yet.

Premium voice morphing renewal is still returning "Sorry, there was a problem activating your new voice font pack at this time, please try again later." We premium users should get a partial refund while this is broken. Yes, it's a minor feature, but we paid for it and we're not getting it.

It looks like making something a character overrides regular collision detection. Collision detection is based on a capsule around the character and the actual geometry does not matter. Collision with a "character" always reports a collision with link #1. Can't find any way to tell where the collision was. There's no function like llDetectedTouchPos for collisions. If the pathfinding system itself is that information-starved, I can see why it does so badly when a character brushes against something.

Pathfinding tester. Two prims, top part is the root. I'm trying collision handling for pathfinding objects, to deal with situations where pathfinding fails. This is a "Character" (llCreateCharacter has been called) but it's being moved with multiple llSetPos calls, not pathfinding functions. This generates a smooth move and collision events. It reports collision_start events with the floor object ("Stone Floor"). I want to filter out floor collisions. So I put a hemisphere on the bottom of the object, so only the hemisphere touches the floor. The hemisphere is a child prim. default { state_entry() { llPassCollisions(PASS_NEVER); } } The child prim has this script. Now, supposedly the child prim/floor collisions go to the child prim first. With llPassCollisions set to PASS_NEVER, collisions should not be passed to the root prim. But they are. The root prim gets collision_start events with "Stone Floor". So the script thinks the character bumped into an obstacle when it was just gliding across the floor. How can I ignore the collisions with the floor?

Pathfinding tester. Two prims, top part is the root. I'm trying collision handling for pathfinding objects, to deal with situations where pathfinding fails. This is a "Character" (llCreateCharacter has been called) but it's being moved with multiple llSetPos calls, not pathfinding functions. This generates a smooth move and collision events. It reports collision_start events with the floor object ("Stone Floor"). I want to filter out floor collisions. So I put a hemisphere on the bottom of the object, so only the hemisphere touches the floor. The hemisphere is a child prim. default { state_entry() { llPassCollisions(PASS_NEVER); } } The child prim has this script. Now, supposedly the child prim/floor collisions go to the child prim first. With llPassCollisions set to PASS_NEVER, collisions should not be passed to the root prim. But they are. The root prim gets collision_start events with "Stone Floor". So the script thinks the character bumped into an obstacle when it was just gliding across the floor. How can I ignore the collisions with the floor?

Try the surf shop on the beach at http://maps.secondlife.com/secondlife/Frozen Banana/76/61/21. Good surf. Pacific West also has surf, but it's kind of mechanical looking. I'm not sure if boards and waves have to be made compatible to work.

You'd probably want to use FBX format, which is the de-facto industry standard for game assets. Autodesk defined it and their tools support it. Unreal Engine 4 supports it. Blender supports it. Lots of assets are available in FBX format. Converting SL assets to FBX wouldn't be all that hard.

There's some interest in the OpenSimulator community in making a viewer that's based on Unreal Engine 4 but plays SL-format assets. The asset format isn't that complicated. It's a subset of what modern games support. The only really incompatible part is scripting. The OpenSimulator people already have an LSL interpreter, so that's covered. (A modern version of SL might be a UE4 viewer on the front end, OpenSimulator on the back end, SpatialOS for scaling, funding from Epic Games's new $25 million fund for big MMO worlds, and a program to identify the top 100 creators in SL and get their permission to move their assets to the new system.)

LL is obsolete technically but it has the user base, creator base, and content. Those are the assets that keep Linden Labs alive. This is the reality of Sansar: Sansar usage on Steam. 11 concurrent users. SL has about 40,000 right now. Yes, there are non-Steam users, creators who signed up, etc. It's "early access". Excuses. Denial. Reality is that Steam's users have decisively rejected Sansar. It's not just Sansar. All of the "game loader" systems - High Fidelity, SineSpace, etc. have tiny user counts. Those are not shared virtual worlds. They're game level loaders where you get to download a user-created level map and play multiplayer with a few people who downloaded the same level. This model has been decisively rejected by the market. With or without VR goggles. It's Sansar that's near death.