Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by animats

  1. Ouch.

    Much of the trouble with region crossings comes from a bad network protocol design decision. When an avatar changes regions, there's a message to the viewer to tell it the handoff has happened, after which the viewer sends user inputs (keyboard, mouse clicks) to the new sim, on a different server with a different IP address. Unfortunately, this seems to be synchronous - the sim needs to receive a reply from the viewer for that message, and the region crossing is delayed until that happens. So delays in the network or the viewer affect region crossings. Add 1 second of network delay, which I've done using a network testing tool, and double region crossings fail every time.

    So, if you minimize or suspend the viewer and carry its avatar across a region boundary, there's going to be trouble.

    This violates the "never trust the client" rule in client/server game design. The sim should never wait for the viewer. The network path handoff and sim crossings should not be so tightly coupled. But it probably seemed like a minor problem 15 years ago, before vehicles.

    (Fixing this is complicated, partly because many things viewer side are in sim-local coordinates. When the viewer changes to a new primary sim, those have to be patched. Object updates can arrive out of order, messing up the hierarchy (sit object/vehicle -> avatar ->attachments). There's a mess in llViewerObject.cpp after line 1982 in the viewer that tries to untangle this. If you read C++, that huge function is worth looking at. Making that work during an asynchronous region crossing, with object update messages coming in from both the losing and gaining sims, would be hard. Comments in the code indicate an attempt to convert the viewer to using 64-bit world coordinates for everything, getting rid of sim-relative coordinates, but that was never finished.)

    • Thanks 2

  2. 11 hours ago, Bitsy Buccaneer said:

    It was just a wee joke and observation. Mostly it was a joke.

    For those who want to take the observation seriously, is there interest in brainstorming ways to engineer the social aspects as well as the technical?

    This came up at Creator User Group last week. I made the point that Project Arctan needs some carrot to go along with the stick. Creators need more automated help with LOD generation. It can be anywhere along the chain. Tools in Blender and Maya. A better mesh optimizer in the uploader. A background task generating impostors for existing objects. A general impostor generator in the viewer. But something.

  3. The only part of the viewer worth putting on a faster device is the viewer cache. The viewer program itself doesn't need to be installed on RAM disk.

    You can put the viewer cache where you want it from the Avatar->Preferences->Network and files->Directories menu.

    Putting the viewer cache on a solid state drive speeds up texture loading quite a bit on machines where the main disk is a rotating hard drive. You need 10GB of space,  though. So doing this with a RAM disk takes a lot of RAM.

    Also, if you put the cache on a RAM disk, you have to reload every texture and mesh when you reboot.


    • Like 1

  4. rollerfreightgirl29li.thumb.jpg.28cab1105ee8770b622020b9eb1797af.jpg

    Dacy, my latest animesh character. 29 LI as shown. I was sent a copy of those shoe textures. Thanks. I made up some workout wear. All the clothing has to be composited onto the skin texture in Photoshop. When animesh get Bakes on Mesh in "Animesh 2", that may improve. For now, it's a big pain to change clothing on animesh.

    I've tried some of the freebie places. But this is animesh. I need the raw texture files in Photoshop. At least until animesh get Bakes on Mesh or some way to change clothing in-world.

    I'd much rather buy animesh clothing from SL's large community of clothing makers. I'm working on scripting good NPCs, they have to wear something, they have to be low LI, and there's little that I can buy, so I had to make a detour through basic clothing construction. It's old-style system clothing, of course, but because these characters are usually in motion, it's not very noticeable.

    (Dacy is currently running around my workshop in Vallone. She's using my new pathfinding system. Not done with that yet, but it's good enough to let a character use it in public. I have two other characters running on the SL pathfinding system, so people can compare behavior. Dacy is the fast one. I've finally overcome the problem of NPC characters moving at zombie speed.)


    • Like 1

  5. SL-Avatar-Bottom-512.jpg

    OK. Here are the SL standard "Lower"  UV layouts. Where can I get shoe textures that use these templates? A basic sneaker would be enough for now. Thanks.

    All I need for now are boring old texture shoes. Like these.


    I know they are obsolete, but someone must have old-style textured shoe files around somewhere. Let me know.

  6. 9 hours ago, OptimoMaximo said:

    For hero-sized objects such characters, it's the most common setting. (50% triangle reduction per LOD level)

    Hm. This suggests how Project Arctan might do character LI:

    • Characters have land impact using the animesh formula: 666 tris = 1 LI, half that for each lower level of detail.
    • Regions (or parcels, or viewers) can specify a maximum LI per character. This doesn't count against parcel LI.
    • If a character is over the maximum, its LOD ranges are reduced so that it switches to a lower LOD sooner. If it's still over, it's rendered in impostor mode. If that doesn't work, it goes to jellydoll mode.
    • The nearest characters still show at full LOD at short range, 4m or so. So you can still admire your friends million-triangle avatars when you get close enough. But a roomful of them won't choke the viewer.

    Now this provides an incentive to get the lower LODs right on avatars and clothing.

  7. Nice. And works for avatars, too, not just simple objects.

    Will there be a Blender version?

    "A perfectly industry-standard-aligned set of LoDs models (50% the triangle count of LoD above) " - didn't know that was an industry standard.

    It works well for animesh. But for objects, it means background objects have significant numbers of triangles. "Lowest" is only 1/8 of "Highest". A 30,000 triangle shoe (not unusual, rez a shoe you have in inventory and look at it in edit) is still 3750 triangles when it's 250m away. As a rule of thumb, you can have about 1 million triangles on screen in SL before the viewer starts to choke. (Expensive graphics cards increase this number.) So a pair of shoes a sim away are 0.7% of your scene budget. Distant over-meshed objects will choke the viewer.

    Maybe drop to 33% between LODs? Then you're down to 370 triangles at full distance. 0.07% of your scene budget.

    LL is  talking about Project Arctan again, redesigning the LOD calculation. Right now, there's too much reward for getting the lowest LOD down to some useless value like 2. Or at least creators think there is. So this is worth discussing now.

    (This week's clothing LOD annoyance: I have an animesh character which has a skin that looks good down to "low" LOD, and at least fills the space at "lowest". Someone gave me a dress to try. It's about 30,000 tris at "High" LOD. Medium LOD is 2. Two. Back off 5m and the dress disappears, leaving the character looking semi-nude, with junk triangles instead of a dress. At 5 meters range.)


  8. Shoes. Shoes seem to have totally insane triangle counts. Like 30,000. Each shoe.


    Animesh character. Bento.  29 LI without shoes.

    I'm still trying to find shoes for my animesh characters, where LI really matters. 666 tris = 1 LI for animesh. A plain pair of sneakers would be fine. I can use system shoes if I can get the texture files. Mesh if I can get it with full perms. This character can wear most mesh clothing designed for standard avatars, but the LI will jump to somewhere between 90 and "sim full". That's no good.

    Animesh don't do "wear" yet. That's coming, Vir Linden says, but it's a ways off. Meanwhile, we have to composite textures in Photoshop and upload, or link objects as prims to add mesh clothing. Animesh are not yet easily customized, which is why we're seeing identical clones repeated around SL. So there's no end user market for animesh clothing.

    • Thanks 1

  9. 5 hours ago, Lucia Nightfire said:

    Ownersay spam is a known spam vector. There have been "combat HUD's" in the past that offer obfuscated titled objects to targets to get them to rez/wear that would crash them with ownersay spam.

    Ah. No surprise. Anyway, llOwnerSay was definitely the problem.


    Turned off most llOwnerSay debug output. Working now. 20 objects in the sandbox, all trying to go back and forth between the same two points while avoiding collisions. Viewer steady at 30 FPS, the max I have set. Script load between 1 and 3 ms/frame, less than regular SL pathfinding. And it drops when objects are not moving. Huge amounts of KFM and llCastRay don't seem to hurt anything. I didn't expect they would; Janet's Viking sim, Folkvang, must have several hundred KFM tasks going.

  10. It's not KFM or scripting. It's llOwnerSay. All by themselves, enough llOwnerSay calls can crash the viewer.

    I wrote a trivial script that makes thousands of llOwnerSay calls. Rez that object, and the viewer slows down to a crawl within minutes, and then "You have been disconnected from Second Life". Doesn't seem to hurt the sim, just the owner's viewer.


    Test in empty Sandbox Goyer. This is Firestorm on Linux, but I've had similar problems with the LL viewer on Windows.

    Sim ping over 5 seconds, frame rate 4.6/sec. Forced logout shortly thereafter.

    UI memory is not becoming large, unlike when I tested with my keyframe animated objects.

    At first, the viewer can keep up, but over a few minutes, it falls behind and gets slower and slower.

    llSay, unlike llOwnerSay, has a throttle. ("Messages sent on channel zero and DEBUG_CHANNEL are throttled to a rate of <200/10sec, per region, per owner/user.") So you can't grief others this way.

    This is a relief. My pathfinding system isn't breaking anything. It's just the debug output choking the viewer.

    Incidentally, notice that the messages, which are numbered, are out of order. Way out of order, like 3000 places out of order.

    (Technically, this looks like an O(n^2) bug. Adding to the queue runs slower as the queue grows, so processing time increases with the square of the message traffic. I had to avoid this once in the logging for a hard real time robotics application. I had the log message queue set up so that when it hit a limit, the output showed "..." and the queue was cleared. That way, the real-time part creating the messages never had to wait.)     

    • Thanks 3

  11. I see something suspicious. Under Viewer/Memory usage/UI, that number starts out around 3000KB and continually increases to 36141 KB. That doesn't happen elsewhere in SL. There's lots of debug print here, via llOwnerSay. You can scroll all the way back in the chat window and look at it, so it's using viewer resources. llSay has some throttling, but you can do all the llOwnerSay you want, I think.  You can only impact your own viewer.

    I wonder if adding text in the chat window gets slower as more text is added. More testing needed. Any known problems in that area?

  12. I've been working on my own pathfinding system, and it's coming along nicely. So I wanted to see how a crowd worked. I set up a test situation with 20 cubes under scripted pathfinding control, in Sandbox Bricker, which was otherwise empty. Everything is running fine. The cubes are maneuvering around each other like they're supposed to, and the sim load is about 2ms/frame, which is not bad compared to regular pathfinding.pathpingafter1mins.thumb.png.2779080e98fb0bd2d40e1c286582e231.png

    1 minute after login.

    But then things start to slow down. The viewer gets slower, and slower.



    10 minutes after the first screenshot. Ping time 21 seconds!

    After about 15 minutes, I get logged out. If I log back in, everything is fine, and the cubes are moving around as before.

    I've had this happen several times now, with both the LL viewer and Firestorm, and on both Windows  7 and Ubuntu 16.04 LTS.


    • The graphics load is trivial. There are 10 cubes and bare ground on screen.
    • Network load is very low. That "ping time" thing is the viewer falling behind, not real network traffic. A ping from a ping program is consistently around 23ms. I have 50mb/sec bandwidth available.
    • No significant disk traffic.
    • Firestorm is compute-bound when this is happening.
    • These cubes are just keyframe-animated, as far as the viewer is concerned. My pathfinding scripts sim side are generating the keyframe list, but the viewer doesn't see that.
    • Script time hovers around 2-3ms/frame. Lots of spare time; this is an empty sandbox.
    • There's a lot of printing from llOwnerSay. I pushed the chat window off  screen here. Can that all by itself jam things up, as the window scrolls to keep up?
    • I have a Firestorm log of this, but since it happens with the Linden viewer too, it's not Firestorm's fault.

    This is strange. I was worried about overloading the sim. That's not a problem. How did I overload the viewer with 20 moving cubes?



  13. 28 minutes ago, CoffeeDujour said:

    Set your sim up as you had it before and do nothing. When you get attacked, report and ban. Forget it ever happened. Don't even bring it up.

    Focus on being able to rapidly clean up and get back to having fun. Enable trusted friends who hangout on the region to moderate and ban. Cook up a little script that keeps track of everyone on the region and messages them a SLURL if everyone vanishes at the same time.

    If you get messaged, instantly mute and laugh, you be the one living rent free in their head.

    Do not allow the infrequent actions of one person to impact how you and others on your regions spend your time in SL. There is no way to prevent someone from being a jerk, just make it as unrewarding as possible, once it starts to feel like a chore to them it will just stop.

    Most of all remember; Attracting idiots is a sure sign that you're doing something right. Maybe rez a trophy for each one you send packing.

    Yes. Also, file both an AR and a bug report in the JIRA. If there's some way to create a script bomb that throws everyone off the sim, that's a bug worth fixing. Script overload problems are getting some attention right now, according to Server User Group discussions. Since you have a full region, you can offer to test an early server release with more overload protection. Go to Server User Group, Tuesdays at noon in Denby sim, for advice.

    • Like 3

  14. Animesh characters can wear shoes. They just can't afford them.



    Couldn't be that complex, could it?


    It could. 30016 triangles. On an animesh character, that's 45 LI. Per shoe. My whole character, is only 30 LI.


    Another shoe drops. 28,308 triangles. 43LI per shoe in animesh model.

    (Animesh LI: 666 triangles per LI at high LOD. 333 at medium. 167 at low. 84 at lowest. Compute all 4, use biggest number.)

    Anyone know some basic female sneakers or casual boots for a standard female avatar with an animesh LI of 1 or 2? I've been downloading demos, unpacking them, getting the triangle count, and deleting them. It's not helping.

  15. I've used keyframe animation with canned paths before. This is keyframe animation with dynamically generated paths and collision avoidance. I just give it the destination, and it figures out the route by itself. It can find and reach avatars anywhere on the parcel. Including going up stairs. I haven't seen that done in SL by anyone else.

    It doesn't even seem to have been done for bots that are avatars. SmartMates (apparently the last survivor of the bot list on the wiki) doesn't have that. They just follow waypoints or the user that owns them. Smartbots offers a kitten, a gorilla, an alpaca, and a bodyguard. Those require a server, a paid account with the server operator, and an extra SL account. Now that we have animesh, we should be able to do that sort of thing entirely within SL.


  16. 1 hour ago, Kimmi Zehetbauer said:

    Silicon Valley company? Isn't LL in San Francisco, way north of the "Valley?" Maybe they might have some servers down there --- but that don't count.

    Somehow, about five years ago, San Francisco became part of "Silicon Valley".

    I live about 30 miles south of San Francisco, about 10 miles north of Stanford. Where I live wasn't considered part of Silicon Valley a decade ago.

  17. Well, after leaving this running overnight, it seems to stay out of trouble. That alone is a big improvement over SL pathfinding. This is starting to look like the way to do NPCs. Keyframed NPCs have worked well in many places of SL, but they're usually stuck on rigid tracks. Now they can get some freedom of movement.

    Keyframed motion in SL is a bit strange. It's semi-physical; it can push or carry physical objects. Collisions with physical objects, including avatars, are detected. But collisions with non-physical objects are not. This includes other keyframed objects. On the other side, keyframed objects don't trigger collisions in llVolumeDetect, and are not avatars or physical objects to llSensor. llSensor will detect scripted objects with type "(ACTIVE|SCRIPTED) ", but that triggers on everything in range that has a script. SL's low-overhead tests for moving objects don't work. So doors don't open for keyframed objects.

    A useful test for doors is to use llSensor with type "AGENT|ACTIVE", then test for nonzero velocity for each object sensed. That picks up avatars, pathfinding animesh, vehicles, and keyframed motion. (Also the door, so that has to be excluded.)

    • Like 1

  18. Pathfinding in SL has been troublesome. I've made some nice pathfinding animesh characters, but they don't move well enough. Characters keep going off-path and running into things. They hit corners of buildings and spin around. They go off-parcel and get stuck. Under sim overload, this gets worse. Much worse. Slowing them down helps, but then they move like zombies. That's no good.

    There's keyframe animation, but that tends to be too rigid, following permanent built-in paths. The movement from keyframe animation works well; it's just too repetitive.

    So I've written my own pathfinding system in LSL. It uses llGetStaticPath to get a rough path, avoiding static obstacles. Then it uses llCastRay calls, many, many llCastRay calls, to check that path. If an obstacle is encountered, it runs a maze solver in LSL and works out a path around the obstacle. Once the path has been computed, the path is followed using keyframe animation. 


    New pathfinding system tester. I'm using a bronze monolith for testing. I'll switch to an animesh character later.

    Just for testing, the planner puts down a trail of temporary markers. They disappear in about a minute. The green path is mostly from llGetStaticPath. That path hit the doorframe. The maze solver took over and corrected that. The maze solver's work is shown in yellow. 


    Though the parking lot and around the parked vehicles. The maze solver worked out a path around the vehicles. The maze solver is grid-based, and the result gets straightened out a bit afterward. Where you see green on top of yellow, the green is the path it actually took. This is actually three maze solves in a row. Looks a bit more robotic than I'd like.

    Using keyframe animation means the characters follow the planned path at full speed, even on an overloaded sim. No more zombie-speed movement. No more banging into doorframes and tables.The movement quality is comparable to ordinary SL avatars. The turns are smoothed out and the character rotates going into and out of the turn; it doesn't stop dead and pivot in place. I'm currently running the monolith at faster than SL walking speed. No problems with that.

    Script overload shows up as a delay in starting movement. Maze solving in LSL is slow, but it's overlapped with movement, so the maze is usually solved before the character gets there.

    The system will avoid avatars when necessary. If an avatar moves into the path, the obstacle will be detected. But then there's a delay of several seconds while the planning system computes a new path. I want to use a "looking around, impatient" animation for my characters while they're on hold waiting for the planner to catch up.

    A big win with this is much better performance in cluttered areas. SL's pathfinding system needs a lot of open space. The minimum opening width for SL pathfinding is about double door width. Even then, the characters tend to bang into the edges of the doorframe. This system, if  there's 1m of space, can get through. So it can get through a standard door. And maneuver around inside a restaurant or club. I'm thinking of a NPC waitress.

    All this requires a parcel with pathfinding enabled, and with big objects marked as walkable or static. The maze solver will handle going around little stuff, movable objects, and avatars. The maze solver can only handle an area of obstacles about 20m across, so big obstacles must be made static.

    This does not turn on the full SL pathfinding system, which has a constant overhead of about 20% of a sim's script time. Overhead for one character seems to be about 1ms per frame. 10 characters in an empty sim pushed the load up to 2ms per frame. So it's less than the built-in pathfinding for small numbers of characters, and there's no compute load when the characters are not moving. Not low enough overhead for large, active breedable herds, though.

    It doesn't seem to impact heavily loaded sims much, because it's making large numbers of llCastRay calls, and those are throttled. So it slows down rather than impacting the sim. That needs further testing. Vir Linden indicated at Creator User Group that making large numbers of llCastRay calls is OK.

    This isn't done yet, but it's working well enough for a demo. I have the monolith running at the Animats workshop in Vallone as a test, and you can visit if you like. The tester behaves much like my animesh NPCs, which use regular pathfinding, and approach new visitors. When there are no new visitors, it moves randomly between some patrol points. It doesn't have the social graces yet. It tends to bump into avatars and stop, it gets too close to them, and it doesn't say "Excuse me" like my NPCs.

    (This was way too much work. LSL is not a good language for something this complex.)




    • Like 2
  • Create New...