Jump to content

animats

Resident
  • Posts

    6,165
  • Joined

  • Last visited

Posts posted by animats

  1. 18 hours ago, Drayke Newall said:

    A solution to this would be for LL to create a mall adjoining learning island whereby it features group gifts from creators with a direct landmark to their store.

    New Resident Island has something like that. There are walkthrough tutorials that get you Ruth or Roth, the open-source avatars, and tell you how to use them. Then there's a freebie area where you can get more clothing.

    The trouble is, there's not much really good clothing for Ruth and Roth. And Roth isn't that well-proportioned an avatar; it's really a Ruth with a flattened chest. (Ankles and shoulders are female sized, regardless of slider settings.)

    What's really needed are starter avatars that come with about a dozen outfits that Just Work, and stores where users can buy more. Preferably fitmesh. Fitmesh is harder for the creator and easier for the user; either it fits or it doesn't. If it doesn't fit, the body sliders will not help the user make it fit.

    Mesh avatar with fitmesh clothing is SL's best clothing system, but it's not the dominant one. A fitmesh-only fashion event might be a way to kickstart this.

    • Like 2
  2. Yes. With EEP, the world is too dark.

    When EEP was installed, the default settings for mainland were set too dark by mistake. But no system was provided to change the default settings mainland-wide. Since this happened while "cloud uplift" was still being finished, it didn't get fixed. Now it's stuck behind the map being broken, group messages being broken, etc.

    You can make your own view of the world brighter using Environment->Personal Lighting. Turn up "Ambient" a bit. Or "Gamma", just a little. Or just set the time to "Midday". But changing that will freeze the sun in place and you will no longer have a day-night cycle. And the viewer will stop responding to places with their own unique lighting, such as New Babbage, which is always rather foggy by design.

    EEP is clever, but like too many Second Life features, work was abandoned at 80% complete.

    • Like 2
  3. 2 hours ago, Wulfie Reanimator said:

    Random thought; would it be possible viable to use a separate object (the same size as the character collider) and for example llMoveToTarget to test for collisions in a more "volumetric" way? And then if there is a collision, optionally do a raycast towards the collision point to check if it's just a small incline on the floor.

    As a means of exploring the world, that bangs things around too much.

    A phantom object doesn't get collision events, so that doesn't help. There are "llVolumeDetect" objects, but they only report collisions with physical objects, which includes avatars. Can't detect walls that way. Rapidly moving an invisible physical object around as an object detector will hit and push around avatars and vehicles.

    In a totally controlled environment, where every fixed obstacle was marked as a static obstacle in the navmesh, you could use llVolumeDetect objects to detect avatars and physical objects. But that means a large amount of parcel prepping. It also won't detect above-ground obstacles like low clearances.

    There's no easy way to do this with SL's current API. It's possible to do it via llCastRay, but it takes a lot of programming.

     

    • Like 1
  4. It's surprisingly difficult to find out if a space is empty. It takes quite a few llCastRay calls.

    My NPCs do horizontal ray casts ahead to check for obstacles. This is done at several heights and widths. I do 9 of those, at head height, waist height, and ankle height, times center, left, and right.

    But that's not enough. I had to add vertical ray casts, to detect thin horizontal planar objects, like table tops. I do five of those, looking downward, to the four corners of a square and the center.

    Even that isn't airtight. It can miss narrow objects like railings.

    And then there are some bugs related to objects with degenerate triangles in the collision model.

    Incidentally, the documentation for llCastRay says you don't get hits reported from the object you're casting from. This is only true if the object is convex. The real check is that you only get hits reported when you hit the outside face of something. If you manage to get entirely inside an object, llCastRay, like the rest of the system, can't see it.

  5. 2 hours ago, VirtualKitten said:

    Oh  its on a sky platform

    Is the platform surface marked as walkable. By default, Linden ground is walkable, but nothing you create is walkable by default.

    Quote

    The wiki says there is a "pathfinding disabled" icon

    If pathfinding is disabled (rarely seen on mainland) an icon with a squggle superimposed a red "do not enter" symbol wlll appear on the top toolbar.

  6. It's hard to tell from that what the problem is. If you have some terrain of your own on top of Linden ground, it has to be set as "Walkable" in Build->Pathfinding.

    Few people know how to set up SL pathfinding properly, which is why I don't sell my NPCs. Takes too much support effort. Documentation is terrible. Two little known facts: 1) if you set "Static obstacle" or "Walkable" for a linkset, all moving parts of the linkset are frozen in place. Including doors. 2) "Walkable" means "Walkable if up to 60 degree slope, then static obstacle", which is very convenient. I have a JIRA in on #1; it's been accepted, but, of course, not fixed.

    Anyway. I have two tools which can help with setup, "Come Here" and "Amulet of Pathfinding". These are both on Marketplace, cheap.

    "Come Here" is just a prim set up for pathfinding. You rez it, click on it, and it tries to come to you, displaying any errors. If Come Here won't move, work on the pathfinding properties of the surface underneath.

    "Amulet of Pathfinding" is a wearable amulet for examining pathfinding properties of objects. Worn on the left wrist. Click on it to turn it on; it glows when on, like any self-respecting magic item. Then go into mouselook and click on ground locations. It does an LLCast Ray and reports the objects hit by the ray and their pathfinding status. It ends with "CAN walk here" or "CANNOT walk here". This is useful when setting up pathfinding.

    In general, SL pathfinding only works well when you have a lot of open space, the pathfinding object moves slowly, and the sim isn't overloaded. Outdoor grazing animals, yes; waitress in crowded club, no.

  7. I'd like to see the water connection between Belli and Sansara improved. You can get to Sansara, but by water, you can't get very far before you reach an obstacle. A few more water sims to the west, to make a connection to Sansara's river system, would help finish the job.

     

    • Like 8
  8. 2 minutes ago, LittleMe Jewell said:

     

    If I was LL, I don't know that I'd worry too much.  I just did a search of "second life forums" on 11 different search engines, including Google (which I'm pretty sure is still the most popular) and only Bing showed IMVU first.  All the rest actually did show the SL Forums as the first result and IMVU was actually not even on the entire first page for all of the other search engines.  

    Even with Bing, if the search is only for "second life", then "secondlife.com" is the first result.

     

    OK. It's always hard to tell who's advertising what how hard to whom. Who and where you are affects search results strongly. I'm never logged into Google or Microsoft, so I see the default results.

    Still, compare the landing pages of IMVU and SL. Boring old IMVU has upped their game.

    • Like 1
    • Haha 1
  9. bingsearch.thumb.png.70a682eb705b573d7d49ef258f8a2b10.png

    IMVU pitch: "Avoid FOMO and Get It!"

    This is what some people get searching for Second Life.

    IMVU's landing page is cooler than SL's landing page. Second Life's landing page now requires a full signup, including date of birth, permission to spam, and a CAPCHA, to find out anything about Second Life. The marketing funnel is upside down.

    No wonder we see so few new users at the new user entry points.

    • Like 2
    • Thanks 3
    • Haha 3
  10. 37 minutes ago, Aishagain said:

    This was precisely what I feared would happen once the region hosting was moved out of LL's own server farm.  It may well save LL's new owners money but SL is no longer the 24/7 operation that it has always claimed to be.  No point in us saying this is not good enough, it is a fait accomplis and it is a significant degradation in the service.

    That's not unusual after a leveraged buyout. This tells us more about the new ownership.

    Watch what they do, not what they say.

     

    • Like 2
    • Thanks 1
  11. 3 minutes ago, Nikkesa said:

    The solution to that is to simply lower resolution locally/do what they already do. They can dynamically allocate further server resources now that they're running on AWS, so definitely shouldn't be a problem server-side.

    Server side is mostly single thread. It doesn't inherently have to be, but it's 20 year old technology.

    There are ways to architect around this. See Spatial OS, from Improbable. Doing it cost-effectively is tough, though. All three free to play big-world games on Spatial OS shut down because they were too expensive to run.

    A more technical view:

    You can sort of see from the performance problems what's wrong server side. Most CPU consumption is script time. Much of that is just the 3us per frame wasted on each script that's doing nothing. 5000 idle scripts in a sim and you're out of script time.

    Scripts could potentially be run in parallel on multiple CPUs. LSL's API has the interesting property that most calls request either get data or put data, but don't do both. The ones that do usually involve a delay. Someone was thinking ahead when they designed that.That allows more concurrency. The way this would be done is that all scripts read the state at the beginning of the frame. All the world state changes a script makes would be accumulated in a queue and applied all at once, after all scripts for the frame have run. If a script does a set followed by a synchronous get, it has to lose a turn and wait one frame. That eliminates most locking problems.

    The other big bottleneck is that when an avatar enters a sim, there's a huge transient load that lasts seconds. Go to a big shopping event and open the performance window and the nearby users window. Watch the performance hit as new avatars enter. This is what causes super-slow walking in busy sims. Why this is the case I don't know.

  12. This is an artifact of Second Life not having physically based rendering. Second Life has an ambient color and a specular color. The effect of both is added. This can push light output past 100% reflective into Full Bright territory. You can get more light out than the lights are putting in. I've had troubles with this on chromed bike parts.

    In a PBR system, you have albedo (overall reflectiveness) and roughness. Roughness = 1.0 has no specular reflection, and the object will have the same brightness regardless of viewing angle and surface normal. Roughness = 0.0 is all specular reflection - totally shiny at the light reflection angle, dead black at all other angles. You never get out more light than you put in.

    So, in SL, if you have both ambient and specular layers, turn down the color slider grey level until you're no longer hitting saturated white.

    • Thanks 1
    • Haha 1
  13. OK. Here's a good test for graphics. The Valley is a test and benchmark for Epic's Unreal Engine 4. You download it and run it, and it shows you a nice forest valley. It looks like a game, but nothing happens except the viewpoint moving around to give you a tour. Start it up and let it run for an hour. It uses CPU, RAM, and the graphics card very heavily. If it runs for an hour with no failures, your computer is fine. If it fails, your computer needs maintenance.

    • Like 1
×
×
  • Create New...