Jump to content

animats

Resident
  • Content Count

    2,051
  • Joined

  • Last visited

Posts posted by animats


  1. 3 minutes ago, Qie Niangao said:

    A sort of Level of Detail in overall dynamic avatar representation as a function of crowd size and distance.

    That's working now in the viewer. In Preferences, set "Number of non-impostor avatars" to about 3. The viewer will no longer choke on large numbers of avatars. The sim still will.


  2. On 6/21/2019 at 2:15 AM, Theresa Tennyson said:

    Second Life at its height has never had concurrency greater than that of Topeka, Kansas. When it was at its highest the system was threatening to tip over under the load. Meanwhile today, with average concurrency around half of its peak, there are still regions that regularly are unable to support all the people who want to go there for certain occasions.

    Second Life is a tiny niche and can't be anything else with the current technology.

    Yes. Draw a crowd in SL and the sim overloads. This is a severe limitation on SL.

    I think it's technically possible to fix that within the current architecture, but it's a bigger job than the current dev team can tackle. And once it worked, you'd need multiple CPUs per sim, running up server costs.


  3. 5 hours ago, Beq Janus said:

    OK, so....we're all kinda right.

    @animats is right that the viewer is able to generate mesh that the user is not (currently) allowed to upload, kind of.

    Yours truly is right that it is impossible to upload a mesh asset that does not have matching material counts for each LOD.

    @Aquila Kytori is on the right track, that the "unused" materials are assigned a placeholder. The placeholder is a single triangle of zero size. Which somewhere along the way must be decaying to a single vert in the export. I'm not inclined to chase that squirrel just yet.

    Here is what is happening at upload...

    The entry of a key, with the string "NoGeometry" creates an entry in the mesh asset for that material, thus fulfilling my requirement above, there is no way for a user to create this themselves.

    Thanks for all that work.

    "NoGeometry" is not unexpected. That's a documented feature in the mesh file format:

    ""NoGeometry" -- optional, boolean, must be true -- If present, there is no geometry for this submesh. This submesh is just a placeholder to let the simulator/viewer know that there is a texture entry for this submesh with no geometry at this LoD. No additional fields may be specified if "NoGeometry" is present." - from http://wiki.secondlife.com/wiki/Mesh/Mesh_Asset_Format

    5 hours ago, Beq Janus said:

    You really really need to have actual mesh to render or it would require all kinds of additional sanity checks and edge cases, so it creates some dummy geometry to act as a sentinel.

    A bit ugly, but gets the job done.

    5 hours ago, Beq Janus said:

    I need to think more about it and consider the inverted cases such as imposters where you effectively have a null material in the High, that acquires mesh data in the lower LODs. 

    Right. That's why I originally wanted this. I wrote an impostor generator for Blender which generates a low-LOD mesh with a new material not present in the higher detail LODs-. I didn't want to modify the user-created higher level of detail model, adding dummy triangles and materials. That would confuse the user, and possibly mess up something they're doing. Mesh cleanup on their model might delete the dummy triangles, for example. Some mesh functions will try to do something with the dummy triangles, confusing the user. Running the impostor generator more than once might add dummy geometry on each rerun, and preventing that requires bookkeeping data somewhere. So, not a good solution.

    I read the documentation and found the "NoGeometry" file data item. If only I could generate that...

    Quote

    if we can come up with a better solution that allows the uploader to recognise this without making it harder for users to debug their genuine material cockups...

    Yes. The Firestorm uploader has useful messages about what matches and what doesn't match across LODs. But the messages are in the "Firestorm.log" file, which only developers read. If those messages were displayed to the end user during uploads, there would be much less confusion about material and object matching problems.

    Thanks for chasing this down. Now what?


  4. On 6/7/2019 at 12:02 PM, Yorkie Bardeen said:

    I won't argue against the social/psychological theories for dystopia, but I will suggest also that SL mostly lent itself to a darker, more confined version of the future. Open spaces are harder to realize than dense urban scenes- SL is quite small and cramped in terms of pure square meterage.

    There used to be a "Route 66" sim which was a small town in the middle of a big empty desert. It's gone. Nobody can afford a big empty desert in SL. I'd like to have long roads through unpopulated woods, open country, mountains, and such, connecting some points of interest. That's sort of what "open space" sims are for, but they are not used much. We do have that long open water route between Bellesaria and Jeoghot now, but there's nothing comparable with land.


  5. 11 hours ago, Beq Janus said:

    I'll have a look at how it works when I get a chance. but yeah, as far as I can tell there is absolutely no way to upload a mesh without having at least one triangle per submesh (where a submesh is what we're calling material)

    what you are seeing as vertices are probably very tiny triangles is my guess.

    However, until I look that remains conjecture, so I'll take a peek when I can

    Thanks. Somehow the built-in LOD generator pulls this off. Tiny triangles? Degenerate triangles? I dunno.


  6. 14 hours ago, Qie Niangao said:

    If we learned anything from adfarmers, it's that a ridiculously small amount of tier can buy an appalling lot of ugly. Microparcels are weapons of extreme asymmetrical warfare.

    Er, yes.

    hugesigncensored.thumb.jpg.57a09ee6a11a75414d85b617966f2f4e.jpg

    Censored to avoid naming and shaming, per policy. This thing is huge. 25 meters high on a 4m x 4m parcel. That's a standard size Linden road in the background. The sign overhangs the road. This one is in Corsica. There are probably more.

    • Like 1
    • Sad 1

  7. Some test results:

    [23:57] Array update timing test 0.3: Timing tests.
    [23:57] Array update timing test 0.3: Fill array of 1024 in 2.313786 secs.
    [23:57] Array update timing test 0.3: 1024 updates to list of 1024 elements in 4.798160 seconds.
    [23:57] Array update timing test 0.3: Fill array of 512 in 0.421613 secs.
    [23:57] Array update timing test 0.3: 1024 updates to list of 512 elements in 2.094694 seconds.
    [23:57] Array update timing test 0.3: Fill array of 256 in 0.088729 secs.
    [23:57] Array update timing test 0.3: 1024 updates to list of 256 elements in 1.275658 seconds.
    [23:57] Array update timing test 0.3: Fill array of 128 in 0.039960 secs.
    [23:57] Array update timing test 0.3: 1024 updates to list of 128 elements in 0.670230 seconds.
    [23:57] Array update timing test 0.3: Fill array of 64 in 0.039129 secs.
    [23:57] Array update timing test 0.3: 1024 updates to list of 64 elements in 0.674368 seconds.
    [23:57] Array update timing test 0.3: Fill array of 32 in 0.000000 secs.
    [23:57] Array update timing test 0.3: 1024 updates to list of 32 elements in 0.601021 seconds.
    [23:57] Array update timing test 0.3: Done

    Performance is independent of list length up to 128. Then it gets worse, linearly. So using multiple lists no longer than 128 seems to be an useful optimization.


  8. I doubt there's a faster way, but I'll ask anyway.

    Is there any way to update a single element in a list, by index, that's faster than llList2List? I know, lists are immutable and a new one has to be created for every update. I was hoping that, just perhaps, there was a built in Mono optimization for

    lst = llList2List(lst, [n], ix, ix);

    which could, if recognized by the compiler as a special case, be done very efficiently. But there's not. Making 1024 random updates to a list of 1024 integers takes 4 seconds in Animesh 1 on the beta grid and 8 seconds in my home sim. Because, of course, it's recopying the whole list for every update.

    Is there any trick for manipulating large arrays in LSL?

    (I'm trying to write an A* algorithm. Doing this in LSL is like pounding a screw.)


  9. On 6/18/2019 at 7:17 AM, Vir Linden said:

    Thanks for the comments! We currently have a project underway to improve some of the pain points with mesh upload. We could potentially tackle more things there, with a strong preference to anything that's well defined and limited in scope. As Beq says, the best way to get this kind of thing looked at is to file a JIRA; new bugs filed as feature requests get evaluated weekly.

    I'm trying to get some consensus on how this ought to work first. You can't discuss that on the JIRA system, because you can't comment on other people's JIRA entries. So this is a good place to discuss it. A JIRA will follow if there's reasonable agreement on how this should work.


  10. cylindertest04.thumb.png.bdf2e913b7c03b6e10178e0af205fec4.png

    Cylinder at medium LOD. Four sides, four colors, a tetrahedron.

    I've looked at it in wireframe, and I've looked at it at very close range. There are only four triangles and four colors there. The extra materials aren't hidden inside; if you get the viewpoint inside the object, you see nothing, since the faces are one-sided. I don't know how the lower-LOD generator makes the unwanted materials go away, but it definitely does it.

    • Like 1

  11. 5 hours ago, Sunbleached said:

    Hello! I have a boat script, but when I stop it remains in the position in which it was at the time of the engine shutdown.

    That's what boats normally do. That's what vehicles normally do, both in SL and RL. Why do you want them to align to an axis when you park?

    • Thanks 1

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

    materialtesthexagon01.png.b9d371d44004ed618bad40df662993f1.png

    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.

     

    materialtestlowlod.thumb.png.b4c57abbda34714d48b6bcf77601efc0.png

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

     

    materialtest02.thumb.png.491d9bbcc54bb43f7d5290accbc52f49.png

    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.

     


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

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

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


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

     

     

     

    • Thanks 1

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


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

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


  20. 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
×
×
  • Create New...