Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by animats

  1. 6 hours ago, Beq Janus said:

    If you can find a mesh that reproduces this then I'll definitely dig into it. I don't believe it is the case because the internal mesh asset format has no way to deal with such an eventuality. I believe that at least one of the MAV missing level of detail messages is due to this. I will have a look when I get some spare cycles.

    What happens if you force the uploader to generate fewer triangles than materials in the lower LODs? This.


    Simple test case - 8 faces, each a different material and color

    This was uploaded with the default generated LOD settings, which forced all the lower LODs down to 8 triangles.



    Low LOD. It looks like two triangles, one on each side. But mesh information says 8.



    Same thing in wireframe. Only two triangles. Unless maybe they're on top of each other? I'm not seeing the texture-fighting that usually happens when you have coincident triangles, so that's unlikely.

    Somehow, the uploader disposed of 6 of the 8 materials for the low LOD. But what did it do with them? It looks like the reduced mesh generator can get rid of unwanted materials, somehow. Even if we can't do that with manually generated LOD files.

    I left this object at Animesh1/145/212/23 on the beta grid if anyone wants to look at it.


  2. workflow_2x.png

    • Alphabetical ordering of prims. Yes, as Beq points out, it's silly. But the uploader used to follow the order in the .DAE file, which you can make Blender sort alphabetically. Or so says this forum comment. That's why I suggested the current random behavior should be made to work the way the only available documentation says it does. Anyone have a better idea? Logically, you'd have the root prim as the parent in the Blender/Maya hierarchy, with the child prims under it. But (I think) parenting is currently interpreted as "merge all the children into one mesh".So that's out.
      7 hours ago, OptimoMaximo said:

      What i try to convey here is that, since the nature of collada files and the uploader don't cater to your needs (as Beq explains above), nothing stops you from writing a utility script Blender/LSL that does a link order change for you automatically based on your Blender scene's selection of objects. Python is pretty powerful and has a lot of tools to very easily manage strings and arrays.

      Nothing you do Blender-side helps when the linking order gets randomized during upload. I need to construct some test cases, but some weird sizing problems seem to appear in out of order link uploads. More on that later.

    • Removing the restriction of all LODs having exactly the same material list. Documentation claims the lower LODs only have to be a subset of the higher LOD. The error message even reads "Material of model is not a subset of reference". And when the built-in mesh reducer is used, it can create models that don't use all the materials. Find out how the "Generated" LOD system does it, and that should help to figure out how to do this.

  3. 8 hours ago, Luna Bliss said:

    Could Spatial OS come to SL once they fly to the clouds? :)   But...I don't know...it seems SL has sharply veered off from any type of metaverse scenario, but sure would be good to have region crossings be smoother.  Wouldn't SL have to be rebuilt from the ground up and break existing content?

    Wow we can get into Sominium Space now, beta...I might try it out.

    SL on Spatial OS has business problems. You have to host on Google's servers, and it's not cheap with a large user base and lots of in-world objects. Which is why they lack AAA titles. But if they solve the scaling problem, someone else will probably do something similar, minus Google.

    • Thanks 1

  4. UpdateSitTarget(){
            vector size = llGetAgentSize(agent);
                rotation localrot = ZERO_ROTATION;
                vector localpos = ZERO_VECTOR;
                if(llGetLinkNumber() > 1){
                    localrot = llGetLocalRot();
                    localpos = llGetLocalPos();
                integer linkNum = llGetNumberOfPrims();
                    if(agent == llGetLinkKey( linkNum )){
                        float fAdjust = ((((0.008906*size.z) + -0.049831)*size.z) + 0.088967)*size.z;
                        [PRIM_POS_LOCAL, (SitPos+<0.0, 0.0, 0.4>-(llRot2Up(SitRot)*fAdjust))*localrot+localpos,PRIM_ROT_LOCAL, SitRot * localrot]);
                        jump end;
                }while( --linkNum );

    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?

  5. A few things the mesh uploader ought to do better:


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


    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.





    • Thanks 1

  6. 4 hours ago, Luna Bliss said:

    I had not heard of Nostos...it looks gorgeous, like walking into a storybook adventure.

    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.

  7. 6 hours ago, Luna Bliss said:

    VR is the future, and in its infancy.

    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.

    • Like 1

  8. 4 hours ago, Lucia Nightfire said:

    Simple script features not tied to major features that tie up a single dev for 1.5 - 2 years could help evolve the platform and could be implemented in far less time.

    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.

    1 hour ago, Gindipple said:

    And I bet you the percent of people leaving second life or the percent of new customers going to other places has very little to do with the amount of new features being added to second life compared to people simply wanting new things like Sansar or VR Chat

    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.

  9. sansarpeakjun8-2.png.440cb06a8745bfde2cead820ff502d95.png

    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.

    • Haha 1

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

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

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

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

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

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

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

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


  • Create New...