Jump to content

animats

Resident
  • Content Count

    2,049
  • Joined

  • Last visited

Posts posted by animats


  1. 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.


  2. 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"

    animeshgirl30lijpg.thumb.jpg.fbe618930d4

    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.


  3. 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.


  4. 20 hours ago, Aishagain said:

    Oz and Simon are far more knowledgeable than us oldtimers but, and it's a big but, they are very few and are less "hands on" than they were.

    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.

     

    • Thanks 1

  5. 11 hours ago, CoffeeDujour said:

    I'd like to see all 'auto generated' LODs trashed, and your viewer rolls them on the fly as meshes come in. Not only does that put it entirely in your control, it makes it possible for the decomposition in use to be improved with time.

    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.


  6. 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.


  7. "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.

  8. 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. 

     


  9. 4 hours ago, Qie Niangao said:

    Hmmm. A single core runs multiple threads, it just can't run them in parallel, so it can't get any benefit from steps to multi-thread the code. If those steps introduced overhead (very possible especially if there are rendezvous sync points) then the simulator could indeed have gotten slower as a result of multi-threading if there are no processors to spare.

    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.


  10. 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.


  11. 16 minutes ago, Scylla Rhiadra said:

    to the "look" of SL -- including the jerky movements from lag, weird shadows and lighting effects, and so on

    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.

    • Like 1

  12. I just discovered that, on Linux, the Firestorm viewer sends all its log message not only to "Firestorm.log", but to the system log. They accumulate in "/var/log/syslog", which many Linux systems keep for days to months. About 99% of the content of the system log is now Firestorm's routine logging. Syslog is supposed to be for major system problems. Is that on purpose?


  13. 18 hours ago, Nalates Urriah said:

    Sort of... Different people (users) have different permissions in the JIRA. That leads to various people (users) providing different answers as to what can and cannot be done in reports. So, two conflicting answers can both be right. Plus, some users can change the security level of the reports and those changes affect what we can do and see..

    If you cannot comment on a JIRA, post another Bug Report and reference the JIRA number you are responding to. If the Lindens can use the info they will add it to their internal report. Solid data is always welcome.

    It's a known bug in the JIRA system that you can't comment on a JIRA entry by another person, even if you have "commentor" permission.


  14. Notes:

    • In Firestorm 6.0.2 "Firestorm.log", during an upload, "WARNING #ColladaDom#  llprimitive/lldaeloader.cpp(92) FSdaeErrorHandler::handleWarning : The DOM was unable to create an attribute xmlns:xsi = http://www.w3.org/2001/XMLSchema-instance at line 11.
      Probably a schema violation." WTF?
    • The "_LOD2", etc. naming convention: This is apparently supposed to be for "Objects" in Collada files. "The viewer uses Name Based Matching to match objects from different LODs in the imported model files. The viewer looks for objects in your Mesh files ending with _LOD2, _LOD1, _LOD0, or _PHYS, and tries to match those object to Medium LOD, Low LOD, Lowest LOD and Physics respectively. If an object doesn't end in one of those, it will be considered for the High LOD. If the viewer cannot match the LODs this way it will resort to the old method of matching which is to rely on the order of the objects in the Mesh files." That's from this Linden Lab QA documentation, which may be a work of fiction.
    • Looking in the Firestorm log, the names Firestorm's uploader uses for objects internally come from the name of the "Mesh" in the Blender sense (black and white inverted triangle in the hierarchy), not the name of the blender "Object" (orange inverted triangle in the hierarchy). Those seem to be the names that need the "_LODx" suffix.
    • The Firestorm log has useful info for the infamous "Material of model is not a subset of reference" errors: 
      isMaterialListSubset : Could not find material Step_top_matl-material in reference model Escalator_mesh
      matchMaterialOrder : Material of model is not a subset of reference.

      This would be much more useful if it was, like, shown to the user.

    • Other good stuff in the Firestorm log:

    Importing Escalatorbodymesh_LOD2 model with 7 material references
    Escalatorbodymesh_LOD2 references Exterior-material
    Escalatorbodymesh_LOD2 references Footplates-material
    Escalatorbodymesh_LOD2 references glass-material
    Escalatorbodymesh_LOD2 references HandRail_000-material
    Escalatorbodymesh_LOD2 references Path_lights-material
    Escalatorbodymesh_LOD2 references Step_side_matl-material
    Escalatorbodymesh_LOD2 references Step_top_matl-material
    
    Importing Escalatorpartmesh_LOD2 model with 1 material references
    Escalatorpartmesh_LOD2 references Step_top_matl-material
    • The uploader knows what it's uploading, which materials go with which meshes, and what's missing when it's unhappy. It even logs that info. It just won't tell the user. The pain for the user is designed in. Muahahaha!

     


  15. On 6/4/2019 at 2:37 AM, Qie Niangao said:

    Agreed, something this, too, is likely happening, but I'd guess unrelated to the general decline in Scripts Run percentage. Anomalies such as the "Sleep Time not associated with Spare Time" thing seem (to me) good candidates for such dramatic cross-sim effects.

    If we see "sheep and goats" sims, some with good performance characteristics and some with bad independent of their own loading factors, those "goats" seem likely victims of resource exhaust on their host-mate sims.

    I'm thinking that, too. My home sim, Vallone, was restarted overnight, and performance has improved from 20% of scripts running to 60-90%. Pathfinding went up from 7% to 50%. Still at 4183 scripts.

    Too many sims on too few servers?


  16. The price increase on premium might be good for SL. Right now, you can do the land baron thing by buying premium memberships, cashing out the stipend, and using the tier to pay for land you rent out. You get 1024 m^2 of tier for about $6/year. This is not good for SL.

    With the price increase, the economics of that trick become much worse. We may see many of the marginal landlords drop out, and we may see less land hoarding of unrented land.


  17. 1 hour ago, Chic Aeon said:

    I have done this fairly often and even made a tutorial on it, but yesterday on the beta grid it was NOT working.

    It's not working right on the beta grid today. I uploaded the same .DAE files three times and got different link orders.

    Beq Janus, who's been working on the uploader in Firestorm, told me that there's a problem, and it's apparently upstream from her code. Apparently nobody does this much.


  18. OK. How do I upload a linkset from Blender 2.79 using Firestorm 6.02 on Windows 7 and get the desired link order in Second Life?

    Looking around, I see bug reports, claims the bugs are fixed, and claims that the bugs aren't fixed despite what the Blender developers say.

    That's from 2016. What's the current situation?

    exportopts.thumb.png.8a3ade47091858793b30d6afb15924af.png

    COLLADA export options

    The claim is that "Sort by object name" makes objects export in alphabetical order. But I've changed names to change the order and re-exported, and not had the link order change.

     

×
×
  • Create New...