Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by animats

  1. I looked through the server release notes for mentions of "thread". At least two things seem to have been moved to a separate thread - object rezzing and parts of region crossings. Both of those are outside the main loop. The main loop in SL is a game loop: do_forever { get_viewer_inputs(); do_physics(); do_scripts(); tell_viewers(); } There are also lots of bookkeeping tasks in the server - profiles, search, inventory, money, chat, voice, delivery, etc. which aren't tied to the frame cycle. Those are probably in other threads. (High Fidelity did their bookkeeping on separate machines, to simplify the sim server. In a new design, that makes sense.) It's the stuff in the game loop that matters for performance. (Mostly. Slow rezzing probably means "the game loop is using all the cycles and the lower priority rezzing thread is being starved.") The argument for multithreading script execution is that script execution is so variable and unthrottled. Land impact limits keep the number of objects under control. Avatar limits keep the number of avis per sim under control. Nothing keeps the number of scripts per sim under control. The combination of idle scripts using time, no limit on scripts, and single thread script execution is making the sim servers choke. Oh, yes. Clock speed leveled off about a decade ago, after doubling every few years for several decades. I'm in Silicon Valley, where people are very aware of this. Fancier superscalar CPU designs have helped some, but that's a diminishing returns thing. Single CPU speed is pretty much maxed out now. But look at cores per chip and their cost. Cores just started getting much cheaper. Yes. SL needs to put more engine behind each sim. But that won't help sims that are in script overload, which now seems to be half of mainland. Those need to be able to use more cores. I think the biggest near-term win would be to try really hard to get the CPU time usage of idle scripts down to 0. If it doesn't have an event to process, it needs to not be looked at all during the frame. Each idle script uses about 0.004ms per frame (plus or minus about 0.001ms) which, somewhere between 4000 to 6000 scripts, chokes the sim. That's got to stop. Oz Linden admitted at Server User Group that a lot of CPU time is going down the drain that way. I suggested that half of SL's CPU load was idle scripts; Simon Linden thought it was less than that. Everyone who's looked at this agrees it's way too big. You can see this using "Asset Search" in Firestorm and asking for "Script Info" with a right mouse click.
  2. Yes. That's a key point. LL claims a huge number of signups per day, but they don't disclose what happens to them. The onboarding funnel is Website signup -> First login to world -> Complete avatar setup -> Get through initial user training -> Reach new user area -> Go someplace beyond new user area -> Stay 1 hour -> Stay 1 day -> Stay 1 week ->Buy premium membership -> Buy land. At each stage, SL loses some users. Where is the big leak in onboarding? That's a marketing problem. Someone needs to be calling up users who dropped out and chatting with them. No, not sending them a link to SurveyMonkey, calling them up and chatting with them to find out what went wrong. It's really important that the number of SL users go up, not down. That totally changes the perspective of investors. The current growth rate is maybe -2%/year. Turn that to +2%, and it starts looking much better. Get it to 10%, and Ebbe gets to give keynote speeches at conferences. Slow performance is a big issue for new users. Read some of those new users "this game sucks" comments. SL is very sluggish to someone who has played GTA V Online or Fortnite. This is a hard technical problem, but not an unsolveable one. LL needs to own that problem and start working hard on it. As users, we should neither make excuses for LL nor accept excuses from LL. Fortnite has a social aspect. SL needs to figure out how to tap into that desire to socialize in a 3D world and start picking up users who want to socialize more and shoot less. The Sansar money drain needs to stop. High Fidelity gave up ("pivoted to enterprise" - yeah, right). Sinespace is less than 100 concurrent users and not going anywhere. Sansar has about 11 concurrent users on Steam. More non-Steam users, but under 100 concurrent users. Sansar has 30 people working on it, one for every 3 concurrent users. SL has 70 for 45,000 concurrent users. The Sansar market segment, which I call "VR game level loaders", is a flop, along with VR headsets. Even VRChat is only a few thousand users. So it's safe for Ebbe to admit failure now that everybody else has failed too. That's a starting point.
  3. 37% price increase! Wow. This is normal for San Francisco, but not for the rest of the world.
  4. As discussed previously, idle scripts doing nothing still use sim time. Somewhere between 5000 and 6000 scripts, they use all the sim time available for scripts. This just happened in Vallone. At around 4000 scripts, the sim was sluggish, but my pathfinding characters still worked. They were getting about 25% of the pathfinding cycles they should, but kept running. Then someone else on the sim built four skyboxes, and the number of active scripts went to about 5500. Pathfinding steps dropped to below 5% of normal. My pathfinding characters now run into walls, go off the parcel, and can't walk in a straight line. They used to work for weeks at a time. Now they fail every few minutes. Pathfinding has lower priority than scripts, so when script time gets really tight, pathfinding almost shuts down. Not happy about this.
  5. The commandments of mainland living. The moles put these up every 2km or so on the main roads of some continents. In some areas, each monument has its own tiny park and rez areas. Obeying these commandments solves most of the problems. Yesterday, at the governance user group, someone learned about autoreturn for the first time. This solved her griefing problem. 5 to 20 minute autoreturn deals with most problems. SL reserves the right to change the rules on mainland. I'd like to see the Bellisseria covenant extended to some mainland areas. Maybe a slow rollout starting in urban areas such as Bay City and Kama City, which don't have much big ugly stuff.
  6. That's a John Portman design. He did several like that in the 1960s. The trouble with doing a skyscraper in SL is that you run out of prims and get a shell building. The best tall building I ever saw in SL is the SYZM Tower in Northbridge. 14 useful floors.Good attention to detail. Lower lobby with retail. This is the headquarters of the SYZM conglomerate, major sellers of modern roleplay equipment in SL. Police cars, phone systems, work vehicles, office equipment - they have it all, and they have a big mall nearby where it's sold. The building has elevators and many furnished offices.
  7. I wonder how many Linden homes will be needed to satisfy demand. We might get the rest of the continents connected through sheer need for Linden home space.
  8. We all know about SL's sim-side performance problems. The usual solution today in other applications is to put more CPU cores on the problem. When SL was designed, the typical server had one core and ran about 3 GHz. So SL's sim programs are single-thread. They can't use a multi-core CPU effectively. Today, a typical server has 8 or more cores and runs about 4 GHz per core. You can get more cores today, but you can't get much faster ones. With the move to AWS coming, LL will have much more flexibility on how many CPUs are available to a sim. If sims were multi-threaded, enough compute power could be applied when needed to make even Fashion Week sims work without choking. So we had some discussion today at Server User Group about what it would take to add multiple core usage to script processing. Script processing is the big variable load sim-side. If a sim is overloaded, it's usually heavy script load. (Yes, there are exceptions.) So what would it take to parallelize LSL? The concurrency rules of LSL: Each script is processed sequentially. You never interrupt one event to run another event in the same script. So you don't need locks in LSL code. There is no order guarantee across multiple scripts. You have no control over which scripts run first. Each script is guaranteed that, within an event that doesn't have a delay (llSleep or a forced delay), the values you get from get-type operations like llGetPos will not change. (It's not clear there's a formal guarantee of this, but scripts seem to expect it.) OK. So let's suppose multiple scripts could run at once, on different CPUs. This is quite feasible. The problems come from two scripts changing the same world state information. In code that was never written for concurrency, adding locks after the fact is risky and difficult. A very clean approach is needed to make this work. So, suppose it works like this. All state changes to the world (all llSet... functions) queue up a change item but don't change the world immediately. llSetPrimitiveParamsFast already works this way. It's asynchronous. You request a change, and it happens some time later. Synchronous llSet... functions, like llSetPos, would also queue up a change item, instead of being applied immediately like now. But they'd also set a "changed" flag for the script. This indicates that the world info obtained with llGet... functions is out of date. Calling a llGet... function when the "changed" flag is set causes the script to be paused for one frame before the value is fetched. This way, if you do llSet... followed by llGet..., you get the new value, one frame later, and you're back in sync. This has the same effect as the "forced delay" mechanism now, but it's applied later. Note that you can do many "llSet..." operations before being stalled one frame time. It's only when you do "get" after "set" that you have to wait for the world to catch up. At the end of a frame cycle, after all scripts have finished their event or were interrupted, all change items get applied to the world. If two scripts queued up change items, the last one wins. All script "changed" flags are cleared. OK, this is confusing. It's a lot like the way a database transaction or a superscalar CPU fence works, though. So this isn't new, it's just a widely used concept translated to the SL world. Now here's where it gets interesting. It would be a problem if an LSL function set something immediately without a forced delay. To make those functions work asynchronously, a one frame delay would have to be inserted. Classic LSL functions that change things almost all have a forced delay. Or they are explicitly asynchronous. It looks like the original designers of SL were preparing for concurrency in the future. Someone was thinking ahead. When you think about it, it's unusual that so many LSL llSet... functions are "blind" - you don't get a completion status back. That's exactly what you want in an asynchronous system. Some newer functions do break those rules. llSetRegionPos - returns a status and no forced delay. No reason this shouldn't have a delay, like llSetPos does. llScaleByFactor - returns a status and no forced delay. This suggests the original design rationale of LSL calls was forgotten. Those few new calls could be given a forced delay, to make them like the others. So, looking ahead, this is a way that SL can move into the multi-core era and overcome its performance problems while not breaking existing scripts. I suspect the original designers of SL had this in mind years ago, but multicore CPUs were rare and expensive back then. Now, you usually have more cores than you know what to do with.
  9. Off-parcel rocks in water off the edge of the world are quite common. Especially where land runs almost to the edge of the world with a tiny strip of water. You can buy special rocks for that on Marketplace, all the way up to an island with a lighthouse almost 64m off the edge of the world. Off the world edge, they're harmless. But you don't get to use those on real land.
  10. Cardigan, 75 LI. Jeans, 46 LI. Not going to work for animesh.
  11. What did you get? Program Y? I need something like that.
  12. I've been struggling with that for my animesh characters. I'm currently looking for a very low-LI rigged mesh jacket/windbreaker, something a 20something woman might wear walking around. Full perm, because animesh mesh clothing has to be linked, not "worn". I can find tons of sexy gear, but wardrobe basics are harder. If you have a mesh jacket which, rezzed by itself, is under 1200 triangles, please let me know.
  13. That would be a nice beach house for Bellesaria.
  14. Come on, they just froze the API today and haven't finished the documentation yet. And I'm off working on animesh NPCs now. It's open source on Github; you can fork it and port it if you want. Main problem is that the rendering doesn't get the white balance right to match SL.
  15. I'm trying to do something similar, but for animesh. See this topic. I bought a low poly animesh model from uno.blokke which is compatible with the UV maps for system skins and clothing. I've been putting system skins and clothing on that to make animesh NPCs. It's working pretty well. 30 LI animesh NPC. Animesh only have a skin layer - no clothing layers. So everything has to either be baked on, in Photoshop, or rigged mesh clothing can be linked. T-shirts and jeans bake on, hair, jackets, and dresses need their own mesh. Finding low-poly mesh items for animesh is a problem - most SL clothing tends to be far too dense a mesh. If you know of any good low-poly casual wear mesh items, let me know. "Low-poly" here means about 1000 triangles. I'd like to get one good jacket, one good skirt, and one good pair of boots or shoes with triangle counts under 666 (for animesh, 666 tris = 1 LI) or maybe twice that, to demonstrate that it's possible. Anything out there? Thanks.
  16. There's no SL requirement that lower level of detail meshes be a "subset of the higher level meshes." The only requirements are that they all use the same materials, and that you can't have more than 8 materials per mesh. "Use the same materials" just means that all levels of detail must have at least one tiny triangle mapped to each material in the upload set. That's a bug; it's not supposed to be quite that restrictive. Documentation says that lower levels of detail must use a subset of the higher level textures, not all of them. Here's an example. High and low LOD meshes. The two meshes are totally different. This is one of my builds, a working escalator that carries riders. You can see this in world at my workshop in Vallone, or at Pierce'd & Cut in New Babbage. While it's not that common to hand-build a lower level of detail, SL supports it quite well. Lower level LOD generators that generate new textures do create a problem, in that you have to go back and put some dummy reference to the new texture in the higher level model. I wrote an impostor generator in Python which generates a texture atlas. That's the texture of the impostor mesh. To satisfy the uploader requirement, you have to map that new texture to some useless tiny triangle in the higher LOD models. You can see my impostor generator source code on Github. Automated level of detail generation was just turned on in Sansar this month. Anyone know how that's working out? Comments from qualified people would be appreciated. Some of us are trying to solve this problem, rather than merely claim it can't be fixed.
  17. Use a plain backdrop. Make sure the image has good white balance. Don't clutter up the image with text. Let us see the product clearly. There may be other pictures, but always have one that just shows exactly what you get.
  18. Ubuntu 16.04 LTS, mostly. I also have an old Windows 7 machine for when I need the Linden viewer.
  19. Linden Labs told creators not to worry too much about mesh complexity. Fine. But then they didn't follow through and put in the heavy machinery to help with making mesh more efficient. When you create a prim, even a complex one with twists and other effects, the system takes care of its visual representation and level of detail models. When you upload a mesh model, what you upload is pretty much what gets pushed to the GPU. This is a problem. This has been discussed before. There are ways to deal with this. The uploader's decimator is terrible. Something with more smarts is needed. At least something as good as the one in Blender. Preferably something better, like Microsoft Simplygon. Simplygon goes beyond basic mesh reduction and does things like convert fine detail in the mesh to a normal map on a much flatter mesh. Great for engraved lettering and such. Game asset generation is more automated than it used to be, and SL is behind on using the available tools. Impostoring in the viewer would help. There's already impostoring for avatars. You can set the maximum number of non-impostor avatars/animesh. Anything beyond that gets rendered 4 times a second onto a flat surface facing the viewer. Looks fine for meetings, not so great for dance clubs. Far better than going all the way to colored blobs. Try it. I normally run with only 3 non-impostor avatars visible. The viewer picks the ones to impostor by distance. The default avatar count for impostoring is so high that it almost never turns on, so this feature isn't used much. It usually does a good job, although avatars with large attachments get clipped. Big skirts, long weapons, and large animesh companion animals tend to be partly cut off, because the surface on which the impostor is generated is sized to the avatar. Impostoring of distant objects in general is a possible future viewer feature. All big-world games do this; otherwise they'd choke. Meanwhile, a Python plug-in to help with LOD generation in Blender might help. I started on a Blender impostor generator, and made some progress, but then Blender announced major API changes in 2.8 without nailing down the API. So I postponed work on that until the Blender world settles.
  20. Logged in vs private browsing/not logged in. The animesh forum disappears when not logged in. Any idea why?
  21. I never got around to creating an alt. I wanted to create one for motorcycle back seat testing, and was thinking of making it a crash test dummy. There's a model on Marketplace for that. Didn't need it in the end. Now I may create one for Bakes On Mesh use. The Bakes on Mesh process involves considerable messing with your avatar and you look terrible while doing it. That's a job for an alt.
  22. animats

    Clothing Theft

    The stuff they're stealing, if they're stealing it, looks like obsolete stuff from an SL freebie store. Compare the fitted rigged mesh Lida leather jacket/bodysuit for SL above, which looks quite good, with the Utherverse texture only version. It's like someone took a screenshot and pasted it onto a Utherverse clothing template. Someone could probably argue "transformative use" under US copyright law. It's like taking a picture from Vogue and making it into a paper doll.
  23. The usual comment in SL on people who want residents to complete surveys or help with their homework is to come into the SL world. Spend enough time here to see how it works. Go to some fashion and art events. Visit the pretty places. Read the major blogs about SL.
  24. That's been there for weeks. We can sail from Jeoghot to Bellesaria to Sansara now. Drivers of SL did that route as a group two weeks ago. Region crossing failures are a problem, because there's no place to re-rez anywhere in that L-shaped water route of over 25 sims.
  25. There's something called PrimSwim used by some swim HUDs which handles "are you in the water" for swim HUDs. Can you use that, and be compatible with existing swim HUDs?
  • Create New...