Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by animats

  1. Beq has some good points. I have to go out; more later. What I'm shooting for is: you make it in Blender or Maya, you upload, and you get what you made in SL. Little or no post-upload adjustments needed.
  2. UpdateSitTarget(){ SitPos=DefPos+AnimPos+AviPos; SitRot=llEuler2Rot(DefRot+AnimRot+AviRot); llSitTarget(SitPos,SitRot); if(agent){ vector size = llGetAgentSize(agent); if(size){ rotation localrot = ZERO_ROTATION; vector localpos = ZERO_VECTOR; if(llGetLinkNumber() > 1){ localrot = llGetLocalRot(); localpos = llGetLocalPos(); } integer linkNum = llGetNumberOfPrims(); do{ if(agent == llGetLinkKey( linkNum )){ float fAdjust = ((((0.008906*size.z) + -0.049831)*size.z) + 0.088967)*size.z; llSetLinkPrimitiveParamsFast(linkNum, [PRIM_POS_LOCAL, (SitPos+<0.0, 0.0, 0.4>-(llRot2Up(SitRot)*fAdjust))*localrot+localpos,PRIM_ROT_LOCAL, SitRot * localrot]); jump end; } }while( --linkNum ); } else{ llUnSit(agent); } } @end; } This is a piece of code from a chair's sit script. After an avatar sits, an adjustment is performed based on the avatar's height to put the feet on the ground. The adjustment applied is float fAdjust = ((((0.008906*size.z) + -0.049831)*size.z) + 0.088967)*size.z; which is a cubic curve driven by size.z. It's basically 9% of size.z plus some additional terms. This suggests that someone collected data on avatars and fit a curve to the data. Anyone know where those numbers came from, and if that formula is any good?
  3. A few things the mesh uploader ought to do better: BUGS If you upload multiple objects, you get a link set in SL. The root prim is random. Really random; you can upload the same .DAE file twice and get different link order. That's a silly bug. If you upload textures with a mesh, apparently the textures don't get uploaded. Another silly bug. It's a documented feature with a checkbox in the uploader. Should be fixed or removed. If you upload multiple levels of detail, the documentation says the materials of the lower levels of detail must be a subset of the higher levels. In practice, they have to be exactly the same. (Except when you use a "generated" level of detail - those can have fewer prims than materials and still work, so the server doesn't really require all the materials be used.) The rules ought to be simply that you can't have more than 8 materials over all the levels of detail. Any missing parts can be filled in with "No Geometry" mesh level of detail blocks. This would make creating lower levels of detail by hand or by script less of a pain. PROPOSED FEATURE - SINGLE FILE UPLOAD It should be possible to upload all the levels of detail from one file. The current naming convention for meshes provides enough info to do this. If an upload contains at least one mesh named "example" and "example_LOD2", then it's a multi-LOD upload. This should work as follows. Mesh names "example", "example_LOD2", "example_LOD3", "example_LOD4", and "example_PHYS" are the LODs of "example". This is how name matching works now, but you have to upload them in separate .DAE files. The first mesh alphabetically is the root prim. This is how it's supposed to work now, and used to work. Other prims should be ordered alphabetically, for consistency. Even if they're not sorted in the .DAE file. The center point of the linkset is from the root prim. All other links are relative to that. There is no stretching of lower LODs to fit the higher LODs in the same file. All LODs in a file are in the same coordinate system. So what you see in Blender is what you get in SL. Have a check that the bounding box of a lower LOD is not significantly outside the bounding box of a higher LOD, to prevent some obscure types of griefing. Allow maybe 5-10% oversize lower LODs; beyond that, something is wrong. This replaces the current enforcement by stretching. These are all pain points that have to be worked around by every mesh user now. These problems discourage user-created lower LODs. Or even ones created by scripts in Blender. Blender can do much better mesh reduction than the uploader can, but that feature is not used much, because the file setup is such a pain. With this setup, you copy each mesh to multiple "_LODx" objects, perhaps in a different layer. Then you run Blender's mesh reduction tools on them, and upload. A plug-in to automate that process would be straightforward. No worries about one of the reduced meshes not using some material. You could also generate an impostor - a simple mesh with a picture of the full object rendered in Blender. You can do that now, but nobody does it, because it's a pain to add a dummy triangle to each higher level of detail to provide a dummy use of the impostor image. User-created lower LODs are very rare in SL. I look for them, and find very few of them. I've created some, and it's a lot of trouble and prone to obscure upload errors. It shouldn't be that hard. It should Just Work. Comments?
  4. No idea if it's going to be any good, but it's the first big-budget Spatial OS game, and we'll get to see how their big-world system works in practice. Improbable's Spatial OS is supposed to support big, Second Life sized seamless worlds. There are invisible region boundaries and they move depending on how many players are in an area. So you can have both huge empty areas and small crowded areas. Google is now pushing this technology. They've partnered with Improbable and Unity to put Google Earth into a game engine. So far, the games based on that are unimaginative. There's a zombie hunt in a big city, a ghost hunt in a big city, and a dinosaur hunt in a big city. None of these are as open world as SL. For that, there's Sominium Space, which has building and land ownership in a big seamless world. They're struggling, funded as a Kickstarter. It's probably one guy. But they have a beta working on Steam. They claim they will be out of beta at the end of this summer. The scaling problems which Linden Labs has failed to solve for years are being solved by others. For sixteen years, LL had big-world pretty much to themselves. That's changing. I point this out occasionally, and each time, there are more and better examples. LL needs to get their act together.
  5. VR is the past. It's been around for decades now. I tried Jaron Lanier's original VR headset back in the 1980s, and many VR systems since. The lag has improved, the resolution has improved, the headgear is slightly lighter, and you need less expensive hardware to drive it. Other than that, it's about the same. 5% to 15% of users still get nauseated. That's worse than most roller coasters. The 2017 holiday season was supposed to be the one where VR took over the world. Instead, it was "peak VR". Most of those headsets sold are now in closets or on eBay. None of the VR worlds are doing well. Sansar, SineSpace, and High Fidelity are all under 100 concurrent users. Just not happening. VRchat peaked at around 20,000 on Xmas Day 2017, and then declined. It's now around 8000 concurrent users. The "killer app" for VR right now seems to be Beat Saber, which is very simple but fun and athletic. The next big try at this seems to be Nostos. Big open world, VR-enabled, anime-like, from NetEase in China, using Improbable's Spatial OS. First big-budget product in that space. Demo in late August. We'll have to see how that works out.
  6. Right. Lucia has a list of little LSL stuff she needs to make some things work. I have a list, too, but I've given up on getting anything implemented. I'm focusing on pushing LL to fix known, acknowledged bugs in the existing features. New users coming in from MMOs find SL very sluggish.This is a big problem with growing the user community. SL is slowing down, and we don't know why. Neither do the developers, from what they tell us. This comes up each week at Server User Group, at Content Creators group, and at Drivers of SL. People with long-running well-tuned estates are complaining that their sims no longer run properly. Something has gone badly wrong and LL can't find it.
  7. Oh, that's what caused the brief spike in usage on June 8th. Sansar has 0.2% of Second Life users on Sansar's biggest few minutes ever. Up from the usual 0.03%. Yet LL is trying to hire two back-end developers for Sansar, and none for Second Life. We paying customers of Second Life want more resources put on Second Life. SL performance is down, the developers are overwhelmed, and the users are angry.
  8. Cocoon seems busy. Mostly when Japan is awake. The look is similar to Insilico, with a lighter touch. Sanctuary is up again, with a new quest-giver at the entrance.
  9. Then they become a financial institution, which means additional responsibilities and more fraud attempts.
  10. Does that work only with shadows on?
  11. More notes: I uploaded something with 2 links on the beta grid. Worked fine. Uploaded the same files on the main grid. Order of links was reversed. Worse, scale was for some reason slightly off. Seriously annoying, because it's an escalator which had to fit a specific building space, it didn't fit, and the customer was unhappy. Uploaded the same file on the main grid again. Worked correctly, including being a slightly different size. I used Firestorm, and right now I don't know whether to send the bug report to LL or FS.
  12. "Yes, because that's really what this whole multibillion-dollar industry is all about, isn't it? Inner beauty." - The Devil Wears Prada.
  13. There's a whole topic on this, as someone pointed out. The short version: Minimum animesh: 15 LI. Optimized character which looks like a classic avatar: about 30 LI. Good mesh avatar, nude, as animesh: 80-130LI. Good mesh avatar, as animesh, with good mesh clothing: 130LI to "Parcel Full" 30 LI. Bento animesh, baked on clothing, mesh hair. My test animesh character. Around 10,000 triangles. 666 tris = 1 LI, plus 15 LI for being animesh. This is about as low LI as a good looking animesh character can go right now.
  14. Getting the overhead for idle scripts down to zero or near zero is essential. There are just too many idle scripts in SL, and until recently, nobody thought of that as a problem. That alone would get many sims down to a reasonable load. Trying to get people to delete idle scripts is far harder than fixing it right. It's a data structure design problem in operating systems. The kind of thing people are asked about in Google interviews. Hard, but in the textbooks.
  15. Often I get the feeling at Server User Group that the developers are in way over their heads. LL's tools for diagnosing SL problems seem very weak. Asking people to go to the beta grid and teleport around while someone watches indicates they don't have automatic tools for that. You'd expect them to be running platoons of scriptable bots on the beta grid to exercise things. Especially since there are scriptable bot systems for SL. But apparently not. The sim overload problem seems to have the developers puzzled. No insight on this has come out at the meetings. SL seems to be gradually slowing down, and we don't know why. That's very serious and not getting fixed. And, of course, region crossings remain a problem. A big problem for LL is staffing. Finding someone good enough to deal with difficult internal problems sim side will be very tough. SL is totally different than web programming. The skills that get you a web-related job today are totally unhelpful. SL is all about persistent state. Web services are all about transaction processing. SL is soft real time, an unusual area. Few people other than MMO server side engine devs do this kind of thing, and there are not many of those people. Going to LL is not a career choice that leads to a better job in Silicon Valley. Three years in, you finally understand the internals of this monster. This has little value to your next employer. Anybody good enough to fix the hard problems inside SL can probably get into Google or Facebook or Amazon and make tons of money. They have lots of complicated code with scaling problems that needs attention and will pay for people to work on it. Not that LL is trying very hard. Here are Linden Lab's job ads. Four for Sansar. One, in QA, for Second Life.
  16. Beq Janus has considered generating impostor objects at runtime. I looked into generating them at upload time. This is a big, complex subject, not a quick minor feature. SL really does need to do distant objects better to keep the viewer from choking.
  17. That's a whole genre in anime and SF. The first appearance of this idea is in Simulacron-3, from 1964. The Thirteenth Floor (1999) is the movie version.
  18. A useful pair of proposed functions: float llGetAutoreturnTime(key k) - returns number of seconds until autoreturn happens. Anyone can use this. llSetAutoreturnTime(key k, float secs) - extends autoreturn time. Requires same parcel owner permissions as llReturn. These are for security orbs and parking lot managers, to perform those functions gracefully. Here's how a store parking lot would work. You buy a parking lot, with asphalt, painted lines, and a sign "Free parking while shopping", and put it next to your store. You set autoreturn to your parcel to 2 minutes. The parking lot script notices when a vehicle drives onto the lot, using a collision_start event. It extends the vehicle's autoreturn time to 10 minutes or so, and notes the UUIDs of the avatars that just arrived. Once a minute, it checks to see if the avatars are still in the area. If they are, it extends the autoreturn time some more. As long as an avatar from the vehicle sticks around, the vehicle will not autoreturn. If they leave the parcel briefly, or get logged out accidentally, they have 10 minutes to come back. Customers feel no time pressure. Might have a limit at 8 hours or so, to prevent someone living in a camper on your lot. The "get autoreturn time" function is useful for vehicles. They can warn their driver that they're about to be autoreturned. You could even have an accessory you wear, like a bracelet, that warns you when the last vehicle you rode in is about to be autoreturned. Gives you a chance to get back to your ride. A user-friendly security orb. Object litter is gone in 2 minutes. Legitimate visitors are not hassled.
  19. "Nice to have" features. Perhaps a task for a new LL hire to implement to get them familiar with the system internals. Proposed: llEntryDanger(vector pos) - returns TRUE if you can't go there. Checks for no-script, ban lines, edge of world, avatar on vehicle blocked, object entry blocked. Like llScriptDanger and llParcelFlags, but more useful. Neither of those give you enough info to be sure it's safe. Use case: vehicles. In a "changed" event call with CHANGED_LINK set, signalling an unsit, the object previously sat on should retain permissions over the avatar until the end of the "changed" event. This would allow graceful unsits with animation. The last act of a sit script could then include placing the avatar properly on the ground, instead of atop the chair or bed. Many objects have great animations for sitting down or getting into a vehicle, but getting out looks like a mess. llGetSimStats needs more constants, so that more of the sim statistics can be retrieved. Right now, all you can get is pathfinding steps executed as a percent value. Total scripts, scripts run, etc. would be useful. Partly for monitoring, and partly to tell when some things should shut down. Proposed: llGetDynamicPath. Like llGetStaticPath, but uses the dynamic pathfinding mesh. Useful for when you want to do pathfinding but want more control over path execution. If there's an obstacle in the way, do you avoid, wait, or attack? Depends on the character's role. Also useful for working around pathfinding bugs.
  20. That's a really good idea. There are a few private surfing sims, but the water area is usually too small for a good ride.
  21. Homestead or open space sim? There, "spare time" includes the time the other sims on the same CPU are using.
  22. As I've suggested before for hardware problems seen only running Second Life, run the Unreal Engine 4 benchmark, "The Valley". This is a program to demo the features of the Unreal Engine game engine and exercise the CPU and GPU hard. It displays a large peaceful valley with trees and grasses. It will give you a tour of the valley, and it will run until stopped, reporting frame rate and GPU temperature. This will make your computer work much harder than SL does, and will run on most machines that can run SL. If The Valley will run for an hour, your machine should run SL without problems. If not, you have a hardware problem.
  23. Right. The sim code has a main loop - get info from viewers, do physics, do scripts, update world, tell viewers. Repeat. 45 times a second. That's currently single-thread, and if the sim is out of script time, it's using 100% of one CPU just to do that. When the sim runs out of CPU time, it first sacrifices pathfinding, then script time, then cuts the sim frame rate. Other stuff, such as rezzing, and (not sure about this) some of the bulk copying associated with teleports and region crossings, has been moved to other threads. Those need CPU time too. If there are other cores available in the same computer, that work can proceed in parallel with the main loop. A single sim can now use more than one core effectively. Under heavy load, a sim may now need more than one core. LL puts multiple sims on one computer. The usual allocation is supposedly 1 core for a full sim, less for homestead and open space sims. That may not be enough any more. LL really doesn't seem to have faced that. They're assuming that the sims on one computer will include some that need less resources than others, so that, across all the cores, there will be some spare CPU time. That assumption seems to have broken down. We've seen reports here of people restarting their estates repeatedly in hopes of being assigned to a computer with some spare time. That doesn't seem to work any more. The idle time just isn't there. This is a big problem for LL. Their business model has assumed that the compute load per sim will not increase. It's especially a problem with the planned move to AWS, where cost goes up linearly with the number of CPUs. Look at the "C5" instances, for heavy compute usage. If you buy your own machines, you get better price/performance if you buy more cores, but not on AWS. (AWS has to do this, or they'd get people buying big instances and subdividing them into little instances to undercut AWS's own pricing.) I wonder if LL management has thought this through. There are articles indicating that AWS is a huge financial lose for compute-bound services.
  24. Here's an experiment we might try to get LL to run. Find a region that's struggling with high script load. Copy the region to the beta grid, something which LL does for testing. Put it on a server with at least 2, preferably 4 CPUs, all by itself. Record load on that server. Invite people to visit the sim on the beta grid. Some tasks in the sim code, such as rezzing and sim to sim copy, have been moved off the main thread. That only helps if you have an additional CPU to run that stuff. It's entirely possible that a busy region now needs more than one CPU to run it properly. This needs to be tested and we users need to know. LL has sort of been assuming that one CPU per sim is a maximum, not a minimum.
  25. Yes. As you get the models close to realistic, other flaws become more obvious. Motion is next. SL could get photorealism easier than it could get better motion. Static photorealism is mostly rendering. That's pretty much figured out now. See "Principled BSDF", which is the Disney/Pixar standard for how to express surfaces. It basically has all the render layers you really need. They did this to simplify their in-house workflow, and it caught on. Blender supports it. High-end GPUs can now render it. All this stuff is viewer side. The server just has to tell the viewer, "render this in Principled BSDF mode, using these texture and mesh UUIDs." The viewer does all the rest. It's now mostly "how expensive a GPU do we require the user to get" and "how much bandwidth do they have for mesh and texture data"? The answer right now is "$500-$1000", and "Upwards of 100mb/s." Most SL users aren't there yet. The viewer has to do something reasonable when it doesn't have enough resources to render all that. That's a big headache in the viewer.
  • Create New...