Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by animats

  1. By the way, Realtor® is a trademark. Only members of the (US) National Association of Realtors can use it, and they are rather aggressive about enforcing that. "Real estate broker" is the generic term.

  2. I went there to say goodbye. Walked around for an hour, looked into some vacant rentals, tried the sushi bar, flew around in a mini-helicopter and took video. I'll miss that place.

    But it just wasn't used much. I've never seen more than three people in its five sims.

  3. Here's a scan in both directions. This is vertical, in both directions.

    Ray cast in arrow dir from <195.04470, 16.08895, 35.56000> to  <195.04470, 16.08895, 25.56000>
     Hit #0: <195.04470, 16.08895, 35.31000> Walkable rug
     Hit #1: <195.04470, 16.08895, 35.25266> Opulent Garage
     Hit #2: <195.04470, 16.08895, 35.15000> Stone floor
     Hit #3: <195.04470, 16.08895, 33.88510> Ground
    Upward ray cast from <195.04470, 16.08895, 0.00000> to  <195.04470, 16.08895, 35.56000>
     Hit #0: <195.04470, 16.08895, 33.65000> Stone floor
     Hit #1: <195.04470, 16.08895, 33.88510> Ground
     Hit #2: <195.04470, 16.08895, 35.11000> Walkable rug
     Hit #3: <195.04470, 16.08895, 35.15014> Opulent Garage
     Hit #4: <195.04470, 16.08895, 35.30999> Cast ray tester 0.3


    Cast ray tester.

    Going downward, there's a rug, the floor of "Opulent Garage", a stone ground slab, and Linden ground. The floor of "Opulent Garage" is thin (0.102m). The "walkable rug", added for pathfinding purposes, is 0.200 thick, because pathfinding does not reliably recognize walkables less than 0.200m thick. So here, the floor of "Opulent Garage" is totally inside the "Walkable rug". Which is why the cast ray hits "Walkable rug" before "Opulent Garage" in both directions.

    Similarly, "Stone floor" penetrates into Linden ground, so it gets detected before the ground surface in the upward scan.

    This gives a sense of why scanning in both directions is ambiguous.

    • Like 1

  4. 8 minutes ago, Wulfie Reanimator said:

    Raycast will be your only friend here, but what I suggest is that you add a higher number of collisions to the ray, then cast the same ray from the opposite direction. This will give you a kind of a "cross-section" of surfaces (which you could combine into a strided list) and you can assume anything between those values is solid material.

    Already doing that. That's what produced the red section in my picture above. Works fine as long as the ray cast is started outside the obstacle. It's hard to guarantee that. Especially inside buildings.

  5. 29 minutes ago, Rolig Loon said:

    You at least have a rough idea of which way is "out". 

    Not that helpful. I'm writing my own pathfinding system.


    New pathfinding system.

    • First, it generates a path with llGetStaticPath. That's the straight green and red sections here. (Those colored lines are temporary prims; after about a minute they disappear, but they're around long enough for debugging and screenshots.)  LlGetStaticPath will go around static obstacles and only put paths on walkable surfaces. It doesn't notice anything not in the static navmesh, and has no concept of vertical clearance, so it will go under tables and such.
    • Then it scans forward and backwards from each llGetStaticPath waypoint, using llCastRay to detect obstacles. The red section has an obstacle.
    • Then it runs a maze solver, which uses a grid of cells and works around moderate-sized obstacles, to get past the red section. Doing the whole path with a maze solver in LSL is too slow, but using one to get around obstacles works. Those are the yellow lines.
    • Then there's some cleanup; shortcuts are tried and used to make the path not so rectangular.

    For this to work, the llGetStaticPath waypoints have to be in open space. Otherwise, the endpoints for the maze solver won't be clear and there's no way to get a valid path.


    Here's a hard case. Here's a path around a corner. LlGetStaticPath did that by itself. Then the path was checked with llCastRay calls,  to catch any above-ground obstructions. Works fine.  The translucent circles are LlGetStaticPath waypoints.

    But if there's an obstacle right at that corner, on top of a waypoint, it will fail. The maze solver needs free space on either side of the obstruction. If a waypoint is obstructed, I need to search along the path for open space for the start and end points. That's where finding open space reliably gets hard.

  6. Here's a surprisingly difficult problem - determining whether a volume in SL doesn't have anything in it. I'm doing path planning and need to know that.

    Out in the open, this is easy. Use llCastRay pointed downward and see that the first hit is the ground or a walkable surface. Indoors, though, it's hard.

    What llCastRay tells you is the first face of an object hit in the direction of the ray cast. If the ray cast starts inside an object, you don't detect that object. So if you ray cast from an arbitrary point, you can get a "no hits" result if the start of the ray cast is inside an object. The bigger the obstacle, the more likely you won't detect it.

    If you ray cast from known open space, you can reliably detect an object. So a chain of ray casts from a known good location can check that a path is clear. When an obstruction is found, though, it's hard to find the far side of the obstruction. Ray-casting in the backwards direction from past the obstacle only works if you know how far is "past". And just because you hit an object doesn't mean you're outside it. If it's convex, you can hit it anyway. Big problem with mesh buildings.

    llSensor doesn't help. That just senses the root location of an object, not its surface.

    Volume detect only works for moving objects, and you have to start from clear space.

    Reading object bounding boxes isn't helpful inside mesh buildings - you just get the entire building.

    Am I missing some simple trick, or is this going to take a lot of ray-casting and bookkeeping?


  7. Donald Trump just tweeted on "tokens".

    "I am not a fan of Bitcoin and other Cryptocurrencies, which are not money, and whose value is highly volatile and based on thin air. Unregulated Crypto Assets can facilitate unlawful behavior, including drug trade and other illegal activity.

    Similarly, Facebook Libra’s “virtual currency” will have little standing or dependability. If Facebook and other companies want to become a bank, they must seek a new Banking Charter and become subject to all Banking Regulations, just like other Banks, both National and International. We have only one real currency in the USA, and it is stronger than ever, both dependable and reliable. It is by far the most dominant currency anywhere in the World, and it will always stay that way. It is called the United States Dollar!"

    With this, the SEC actions earlier this week, and reaction to Facebook's new money scheme, Linden Labs/Tilia picked a really bad time to issue an unregulated "token", claim it has no value, and then claim they have no responsibilities for customer assets. The cryptocurrency community has created too many "take the money and run" "coins", and the crackdown has come.

    LL / Tilia now needs expensive securities lawyers to figure out how to be compliant. The worse the user terms look, the more likely the SEC will consider it a scam.

    • Thanks 1
    • Haha 1

  8. orville-walkable-bug.thumb.png.ef20eb0f23699fe84be4ac88f11420c6.pngOrville Airport, Orville sim. A LL-built seaplane airport. I do some animesh NPC testing at this seldom used place. They've been behaving strangely there, detecting invisible obstacles and unable to cross certain lines.

    This is an old Linden sim, all prim, little if any mesh. The grey area is completely flat. It's a few big prims. The boarding stairs are prim, about 50 (!) prims in a linkset. Almost everything in this sim is tagged "static obstacle" for pathfinding purposes, so it's good for pathfinding testing. Pathfinding can get a character up those steps into the terminal, all the way to the control tower. But moving around in the open space in front of the terminal gets weird.

    This view shows the navmesh for "Type A" characters, avatar-like. Notice the bumps in the flat ground. That's a bug. Somehow, those steps messed up the navmesh for a considerable distance around the steps.



    Static path viewed in the viewer. Note the up and down movement. The cement surface is flat, so that's wrong.

    Somehow, those boarding stairs mess up the navmesh for tens of meters in all directions. This is the only place I've seen this. Any insight on what makes this place special?

    (I'm working on some path planning which uses both llGetStaticPath and llCastRay. In this place, they disagree on where the ground is, causing some problems. I need to know if this is a widespread problem, or an unusual special case.)


  9. This keeps happening to large French sims built by cultural organizations. There was a full-scale Versailles in SL at one time, but the tier was too much. So it's gone.

    Can Hangars Liquides be saved into an Open Simulator sim? It's a shame to lose this.

    I've been there many times. I've explored, taken friends there, and even brought in a motorcycle to drive around the ramps.

    • Like 5

  10. On 6/30/2019 at 7:22 AM, Leora Jacobus said:

    I put up a kitchen but all the cupboards are empty. If I fill them with china, glasses and food that will take LOTS of LI.

    I thought about one prim textured with a photo of kitchenstuff  ;) - But I cannot find something like that on the MP

    How do you fill your cupboards?

    I was once toying with the idea of a cupboard where, with the doors closed, you saw a picture. When you opened the doors, the items were actually rezzed as 3D objects. Close the doors, and the objects are deleted and the front of the cabinet shows a picture again.

    The intended use was a store or a library, but it could work for a kitchen.

    One of those farming systems where you work to make ingredients, which you then prepare and cook, could work that way. You and others could see your inventory and the results of all the hard work.

  11. The Linden Labs XML data is partially broken. It looks like this:


    That's where web sites get SL concurrency. Yes, it actually returns "Loading..." in the XML data. I don't think that the transaction data has been released for years. SL used to issue statements about numbers for the SL economy. Then they started dropping.

    • Like 1

  12. Blockstack just got SEC approval for their token.Tilia should go for SEC approval for Linden dollars, and accept that they run a financial institution. The Tilia terms try to weasel out of LL's financial obligations. The honest route is to acknowledge that Linden Dollars are a store of value, and get all the necessary approvals. That's what Facebook is doing for their token. YouNow has a SEC-approved token.

    The way this is going, unregistered tokens and sleazy contract terms are more likely to be a problem for than getting SEC registration as a security. The regulatory environment for "tokens" just changed in a big way.

    • Thanks 1
    • Haha 1

  13. There are a few constraints in SL.

    The parcel system encourages horizontal separation. Stacked apartments exist in SL but are not very popular. If you get too many avis too close together, the system starts to choke. Prim allowances become low. Voice and chat have too much range. Bellisseria has about the right density. The Tuscan sims above are about at that density. Bellagio is much denser, too dense for SL. Dense cities exist in SL, but the buildings are mostly shells. (There's an impressive modern Japanese city in SL, but the tall buildings have little inside above the first floor.)

    One of the reasons Bellisseria is a success is that there's buffer space between all parcels. That was a great idea, and well-executed.

    Another win in Bellisseria is a usable road system. That provides a sense of real world space, even if you don't drive much. Visit the old Linden Homes continents, which don't have a useful road system, and you will feel lost quickly.


    French farm village. A tourist destination. That would work in SL. With about half as many buildings.

    • Like 5

  14. Realize how tiny the SL dev team is. If you go to Server User Group, you'll meet them all eventually. Simon Linden seems to be the only one who works on hard server side problems, and he's way overworked. UE4 probably has 20x as many developers.

    OpenSim is down to one developer, the last time I checked.

    When LL gives up on the Sansar resource drain and assigns the 30 or so  people over there to working on SL, SL might improve. We, as SL customers, pay for that debacle.

    • Like 1

  15. 25 minutes ago, Sunbleached said:


    Hello! Thanks very much for your hint! Yes, it happens sometimes. Could you give a little more detail on what to do, please? (camera and position both)

    In the "changed" event, when you get a CHANGED_REGION event, the script and its vehicle have completed the region crossing. The avatars and attachments may still be catching up. So on a CHANGED_REGION, set a flag like "region_cross_incomplete".

    In your timer or control event, which is executed frequently, check that flag. If it's set, call llGetPermissions and see if you have all your permissions. If not, don't do anything; the avatars are still crossing the region boundary. If you have all your perms, reset the camera, sounds, and animations, the same way you got them started at startup, and clear the flag. This fixes the "camera lost position" and "avatar animation lost" problems. It's a SL bug that you need to do this.

    Robust region crossing requires active management in vehicle scripts. I've written about this before. Other things to handle include:

    • Slowing down to avoid double region crossings.
    • Avatar is slow catching up with the vehicle. This is what the perms issue above comes from. (Sometimes the avatar never catches up at all, and the region crossing fails. Sometimes the avatar gets there first, and appears in a bogus position because it is a child prim, with coords relative to the vehicle. This either rubber-bands back quickly when the vehicle shows up, or leads to a failed region crossing.)
    • Dealing with the "sinking" problem when off the edge of the sim but the region crossing hasn't started yet. (Region crossings start when you're about 1m beyond the sim edge. "Sinking" comes from loss of support from the region being left, before the region being entered has taken over.)
    • Correcting unwanted changes in direction and speed when crossing a sim boundary. Easy to fix; force the last good velocity and omega vectors from the old sim using llSetVelocity and llSetAngularVelocity.

    Most of the better vehicles in SL do some of these things. I seem to be the only builder who writes it up. I've written about this before.

    This is reasonably hard to get right. I had to drive about 1000km in SL to debug.

    • Thanks 1

  16. Ray tracing for worlds as complex as SL's is a ways off. But there is a way.

    The whole graphics system of SL needs modernization, but that's a huge job. One new hire isn't enough. The next new hire will probably be stuck trying to make the viewer use Vulkan (Microsoft) and Metal (Apple). Until recently, you could just use OpenGL on all platforms, but that's changing. Vulkan seems to be the future. There's Vulkan for Windows, for Mac (using an open source adapter called "MoltenVK", if that works) and for Linux.

    This is a job I would consider "hard", "not fun", and "write once, debug everywhere". This is far harder than EEP, and look what a mess that turned into.

    Maybe, if we're really lucky, we get physically based rendering out of this. Principled BSDF, which is a Disney/Pixar standard and which Blender understands, is probably the way to go. It's more texture layers. Right now, SL has diffuse, emissive, specular, and normal ("bump") textures. This adds more textures to the mix:


    Putting all those layers together is something modern GPUs can do fast. Much faster than ray tracing. The main use cases are for skin, for which the "subsurface" layer contributes to realism, and automotive paint jobs, where "clearcoat" and "clearcoat roughness" matter. Most of the time, you don't use all those textures at the same time.

    From an SL perspective, it's almost all viewer side. The server just has to tell the viewer the UUIDs and URLs from which to get the texture images, and some numbers associated with how they're assembled. There's no wiring up of shader plumbing, as with Cycles render. It's close to the way SL represents materials now. So LL might be able to pull this off.

    At lower graphics settings, the viewer would skip some of the more subtle layers. Think of this as "Advanced Lighting Model, Boss Level". You'll need a good GPU. Time moves on and GPUs get better and cheaper.

    What do the graphics people think of this? It's worrisome that, with all the tutorials on "Principled BSDF" for Blender, very few show photorealistic humans. Lots of shiny things, garden gnomes, etc., but not many humans.





    • Like 1

  17. 12 minutes ago, MaxSilverDragon said:

    all these worlds my wind up being bigger than second life but they will not have the freedom of it

    I agree. You can't host adult content on Spatial OS, for example, because it has to run on Google servers.

    Freedom is so last-cen. It's all walled gardens now, where the service has all the rights and power and the peons do what they're told. The New York Times has an editorial on this today.

  18. Advanced hint:

    If you have something that makes a continuous sound that shouldn't sound repetitive, like an engine sound, there's a useful trick. Get a long recording of the desired sound and cut out four samples of 10 seconds or less which, played one after another, sound good in any order. Play them randomly, with the constraint that the same sound is never played twice in a row.

    Why four? Seems to be a limit in human auditory memory. Two samples played alternately sound repetitive. Three samples played randomly sound somewhat repetitive. Four sound unique. Drum machines use this trick.

    I have a squeaky wind vane that does this.

    • Thanks 1
  • Create New...