Jump to content

animats

Resident
  • Content Count

    2,170
  • Joined

  • Last visited

Posts posted by animats


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

     


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

    basicanimeshleggings.thumb.jpg.6d1a1b16e

    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

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

    pathload20-03.thumb.png.1f8e5c0beb10211917ca55641ede94e5.png

    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.


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

    ownersaymsgjam01.thumb.png.86a0c222a90cc852fd695fa926b611bd.png

    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 2

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


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

     

    pathpingafter12mins.thumb.png.c3afdecdcc6d05fdb0b28bc36f4a7e25.png

    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.

    Notes:

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

     

     


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

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

    simpleshoe.jpg.025ec3abde2bb58474ba5f895c62db4f.jpg

     

    Couldn't be that complex, could it?

    shoehighpoly.png.cc9fa97a1dc0f9b088c39f477b834697.png

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

    highpolyshoes.png.02e80abe0b50e6372e54b4fc9c66c0c7.png

    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.


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

     


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


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

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

    paththroughdoor.thumb.jpg.be41d061cb5ad35c716abd477988a98d.jpg

    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. 

    pathpastsomevehicles.jpg.dae1092aa3a7293100084c89f979d85d.jpg

    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

  13. 4 hours ago, Minx Kurosawa said:

    Sadly there isn't much building content out and most of the sim get the same building stuff that other sims already have. And do you know how much it cost for a SL building artist out there to build the sim for you? An arm and a leg. Not only are you paying the Tier .. you end up with a sim full of  regurgitated building blocks content. Unless the SL building artist rigs the content from scratch. You will end up with what other sims already have.

    There are some beautifully built RP sims. Cocoon and Sanctuary come to mind.


  14. I've been doing a lot of scripting work lately, and I'm visibly in world when I do it. I have a workshop, and I use it as a workshop. That seems appropriate. I have a builder's yard out back for big stuff like escalators. Sometimes people stop by while I'm working and I stop what I'm doing to talk to them.

    • Like 2
×
×
  • Create New...