Jump to content

animats

Resident
  • Content Count

    2,163
  • Joined

  • Last visited

Community Reputation

1,823 Excellent

1 Follower

About animats

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. animats

    Shoes for animesh

    Baby needs shoes. 29 LI animesh. Need shoes with a suitably low LI.
  3. 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.
  4. 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.
  5. Yes. A key point for a new user is whether you want to ride a horse, or be a horse. Both options are available.
  6. Oh, come on. L$70K for two 400m^2 parcels in a dead mall where most of the stores are vacant?
  7. 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.
  8. Yes. However, the default "Thomas" avatar comes with a horse attachment. So that's a free option. Not too bad a horse, either.
  9. 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.)
  10. 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.)
  11. At region crossings, or randomly? You have to restart vehicle animations at region crossings to eliminate this problem. It's been around for years, but can and is dealt with in vehicle scripts.
  12. You can set your account to foward IMs to email. If you answer the email with a text-only email, it goes back in world as a reply IM.
  13. There are some beautifully built RP sims. Cocoon and Sanctuary come to mind.
  14. You're not missing anything. "Skill gaming" regions are boring rows of slot machines.
×
×
  • Create New...