Jump to content

animats

Resident
  • Posts

    6,209
  • Joined

  • Last visited

Posts posted by animats

  1. 10 hours ago, Fionalein said:

    Couldn't you just hide two dark grey physical torus prims in the tires? Would also solve any "bike looses tires at zooming out" problems...

    It doesn't seem to matter where the physics weight comes from. It just needs more of it. Bug known for years, apparently.

    Visible level of detail for mesh objects is a separate problem, much discussed in the mesh forum.

  2. 1 hour ago, LittleMe Jewell said:

    Or if there is going to be a central landing spot, there should be a way to randomize it within a specified area.

    Yes. Landing points should have a diameter. You should land somewhere in the target circle.

    Hitting people who just landed with messages or notecards or gifts makes it worse. They can't move until they dismiss all the spam. Avatars pile up while dealing with their inboxes.

    Don't judge by today's performance, though. SL is very broken today. Look at the grid status. I'm seeing so much breakage I'm giving up for today.

    • Like 1
  3. Parts of SL are broken today. I just had extreme half-unsits at the Eichorn Cove / Corchalo crossing. Twice, about half an hour apart. Much worse than usual. Driver avatar ends up in air. Passenger ends up on ground. Bike disappears, and does not show up in Lost+Found later. During the region cross, the bike motor sound climbs in pitch for several seconds.  (There's nothing in the script to do that. There's not even an LSL feature to do that). Logging information from the bike (our bikes log region crossing data to a server outside SL) shows everything normal up to when the bike disappears.  Teleporting out didn't work. Logging out and back in worked for me, but the passenger tried that and seemed to be logged in twice. Their copy of Firestorm lost its settings.

    On top of this, routine stuff is failing. Stalls for five seconds when flying. Diagonally adjacent regions disappearing. Mostly in Kama City; Robin Loop in Heterocera was OK, although a bit sluggish.

    https://status.secondlifegrid.net/ shows problems today, and the problems may be worse than the status page indicates.

  4. Too little physics weight really does break the collision system. I made every object in the bike a convex hull. Land impact went from 17 to 18. The bike no longer falls through the ramp. It sometimes gets "caught" by a nonexistent obstacle on steep ramps, though, just like the prim/sculptie bike.

    There seems to be a critical angle for this bug. Rachel Stardust tried making ramps with different slopes. Over 18 degrees at the break, fail. Under 18 degrees, success.

    Here's the troublesome Heterocera bridge.

    heterocerabridge_001.thumb.jpg.1e7b7cb31fc74d3cc9fdd64fda6da444.jpg

    20 degrees at the break. Way too much.

    That bridge seems to be modeled after the famous bridge at Chappaquiddick, which has been in the news lately.

    Chappaquiddick-kennedy-car-bridge.jpg.541ecc5fb586c87a946b7c4888c019eb.jpg

    A bad bridge design that changed history. Not as steep as the bridge in SL.

    Very few main roads in RL or SL have a break this sharp. There's a steep spot at one end of the Heterocera bridge, and a steep spot on Robin Loop. Those are the only really bad spots I have found, and that's with over 500km of SL driving. What we need here is some mole work on a few trouble spots.

    The steepest street in San Francisco is 17.5 degrees, and the approach isn't a hard break like SL. Given this unfixed physics bug, SL should keep worst case road slopes down to 15 degrees. That's huge by real world standards. 10 degrees is the normal limit for mountain roads. 20 degrees is unrealistic and things break.

     

     

     

    • Like 1
    • Thanks 1
  5. I've tried old show physics in the LL viewer in a sandbox. It's not too helpful.

    Tried Prim mode for the big mesh object. Didn't help.

    The big mesh object works fine at very slow speed. rampslowapproach_001.thumb.jpg.6f0166e9ee35291a2f0452153e308685.jpg

    At slower than walking speed, the collisions work right.

    The translucent blue object is the sled mesh. Only it and the frame (which is the root) are collidable in this test. So here, it's supporting the bike, like it should. Both are set to convex hull. At walking speed, the blue object goes through the ramp.

    The slope determines what happens. Above 18 degrees, fails, even at slow speeds. Below 18 degrees, succeeds, even at high speeds.

    The vehicle system prevents the vehicle from rotating rapidly in pitch. The collision system is trying to rotate it. That ought to result in going up the hill in a horizontal attitude, and for some vehicles, it does. But here, the vehicle goes into the hill. But turning down angular friction or linear deflection in the vehicle params has no effect. That doesn't seem to be it.

    I have a bike from Marketplace which can take this hill at very high speeds. It's non mesh. No sled prim. Torus tires, cylinder wheels, sculpted body.

    Replying to Callum: tried changing big prim physics type to Prim from Convex Hull. Didn't help.

    Show Physics (in LL viewer, of course; it's meaningless for mesh in Firestorm) shows the big sled mesh object looking like the big sled mesh object. That object, all by itself, seems to have proper physics properties.

     

     

  6. So we've spent two hours trying various bikes against that 30 degree ramp. Some fall through, some can climb the ramp.

    • One old super bike does well, even at high speed. Don't know why. The front wheel does go into the ramp momentarily, but then comes out.
    • Huge lag in the sandbox today, but the lag meter and statistics all look good.
    • Big sled prims don't help much. Even a simple rectangular prim can fall through that ramp.
    • Making the ramp thicker, 1 meter, doesn't help.
    • Making the ramp from short sections doesn't help.

    I've seen a "sled" form which is a row of cylinders. I think the idea there may be that if the collision detection system misses one collision, one of the other collisions will be detected and will get things back on track.

    Something else in SL to have to work around.

     

  7. Yes, I reset camera params after a region crossing too. It gets the camera back on track.

    It would be worth looking at the code in the viewer for camera control. It would work better if camera control was aware of region crossings. I think there's a bug where camera control briefly applies the position relative to one region to the location of a different region. That's when the camera suddenly gets hundreds of meters from the avatar, then zips back.

    • Like 2
  8. collidefail1.png.3c4e4b3aa7eecb7f2a2b696d5ac06302.png

    Here's the bike, supported by that mesh object, shown translucent in blue, trying to cross a bridge like the one in Heterocera.

    Collision detection seems to fail here. The simple convex shape goes right through that thin prim.

    Except for this special case, that bike works quite well, and rides nicely on that blue convex mesh object. Rough roads and curbs work fine.

    collidefail2.png.acd03fe077f8d5901ec1cf4c272ba947.png

    Then, stuck - avatar on top, bike underneath.

    It doesn't recover. It gets worse.

    This has to be a known problem. Any comments?

     

  9. Interesting. That's a nice feature in a helicopter HUD. I haven't looked at HUD to vehicle connections. Vehicle to avatar connections definitely have a period of disconnection during sim crossings. A vehicle script can see three things changing during a region crossing:

    • During the region cross, the script may lose PERMISSION_TRIGGER_ANIMATION briefly. Trying to start or stop an animation during that period will cause a script permissions error.
    • The link from the vehicle to the avatar as a child prim remains valid throughout, but the link from the avatar back to the vehicle becomes NULL_KEY while the avatar is separated from the vehicle. Trying to start or stop an animation during that period will cause a "cannot find agent" script error.
    • The distance from the avatar to the sit position may briefly be large. This happens when the vehicle is moving and the avatar arrives in the new sim behind the vehicle. You sometimes see this in world as the avatar frantically zips to the sit position.

    The CHANGED_REGION event for a vehicle means the vehicle has crossed. The avatars may still be catching up. When all three of the conditions above are satisfied for all avatars on the vehicle, the avatars are back in place and ready to go. The usual delay is about one ping round trip time (40ms US, 120ms Europe), but it can be much longer (seconds) if a message gets lost. Vehicle scripts see region cross failures as a CHANGED_REGION event where the avatars never catch up. Most of what we're doing to make region crossings work is to hold the vehicle locked stationary until the avatars catch up.

    Let us know what you find out about HUDs and their connections. I haven't looked at the mechanics of HUDs at all. Do they run entirely in the viewer, or are they moved from sim to sim like avatars and vehicles? This might turn out to be related to the fragility of some clothing with HUDs at region crossings.

    At a less technical level, it's useful to think of SL regions as islands. When you cross a sim boundary, you first go off the edge of the old region, and are then teleported to the new one. The illusion of a seamless world is created by the viewer, which talks to many sims at once.

    • Like 4
    • Thanks 1
  10. I'm working on a motorcycle design in SL, and want to create a better base "sled" for it. So I made a "capsule" shape in Blender.

    capsule.thumb.png.f0b237318735a83211fd98cafd0292f1.png

    Simple capsule shape, faces minimized in Blender.

    I imported this with full detail and no "simplification", since simplification tends to mess up the geometry and make it asymmetrical. This wraps around the bike, and has to slide well over hills and small obstacles. It has to be symmetrical or the bike will not go straight.

    tubeinworld.jpg.1b4feb11e7216657e05370086b03a05c.jpg

    In world

    Here it is in world. As a test, I made it "physical" - it falls over properly and can be pushed around, and will support a physical cube placed on top of it. It's set for convex hull collisions, and since it's a convex object, it should be one perfect convex hull.

    So I made it part of a bike. That mostly works, except for thin road surfaces at steep angles. It falls through those. It consistently falls through the long wooden bridge at the south end of Hetrocera's bay. It falls through a place on Robin Loop where the road takes a sharp upward pitch. Bike and rider get stuck in the road prim. All this is nowhere near a region crossing; separate problem from that.

    This is unexpected. Ordinary prims don't fall through. Mesh wheels don't fall through. An ellipsoid prim of roughly the same dimensions doesn't fall through. Am I doing something wrong here? Known bug?

  11. Large textures alone shouldn't choke SL. The viewer reduces the resolution of textures to fit them into the available texture space of the graphics card. It also reduces them when the object is not taking enough screen space to need that much texture. It's the viewer's job to manage this, not the object creator's. The viewer knows how close the camera is to the object; the creator does not.

    SL's big rendering problem is weak level of detail processing. All the viewer really does is pick which level of detail to display based on distance, and clip the world at the draw distance. That's simple but way below optimal.

    SL needs automatic low level of detail model generation. Expecting people to do a good job by hand isn't working. It's too much work, and it's better done by a program anyway. There are reasonably good automatic systems for that now. (Better than the "decimate" feature in Blender.)

    SL also needs automatic imposter generation. Distant objects need to turn into a bounding box or a cross with a render of the object painted on it. Most game engines have that today. Higher level imposters are needed. Buildings and all their contents should be replaced with a big imposter when far away. There's no way to do this in SL, even by hand. Entire sims off in the distance should be replaced with big impostors, so you can see the mountains and buildings in the distance. SL's frame rate problems are mostly due to too much rendering effort going into distant objects.

    Almost all AAA video games today have all of this. SL is behind.

    It's the job of the viewer to manage frame rate. LL is looking at the rendering pipeline as part of Project Arctan. Maybe things will improve. There's certainly lots of headroom for improvement viewer side.

    • Like 1
  12. The Sketchup CSG approach has potential as an in-world editor. Look at the Sketchup UI. The basic operations and 3D navigation are consistent with SL's metaphors. You move around the model, touch, point, pull, push, and drag. 

    In-world editing beyond the prim level would give SL a big edge over the competition. SineSpace, High Fidelity, and Sansar don't have in-world editing. But look who does. Minecraft. Roblox. Even Fortnite. The worlds that have far more users than SL.  SL is missing out here.

    Face it, the typical user is not going to learn Blender.  Even getting them to use Sketchup is tough. But give them an easy to use in-world building tool, and they can do things. Prims were the right idea for the late 1990s, but there's been progress in 3D editing since then.

    • Like 1
    • Haha 1
  13. I've just spent an hour running NickeyD's branch of Firestorm on Linux. This is based on the LL AlexIvy version.  It's looking good. Went to  Tralala's Diner, a Japanese street market with high detail and good LOD textures. The new texture cache handling seems better than the old. The street market looks good, LOD transitions are working well,. and nothing broke. I tried some fast motorcycle runs around Circuit de Corse, sometimes outrunning the texture loading, and that worked fine. Very nice. Nothing broke anywhere.

    This seems to fix https://jira.phoenixviewer.com/browse/FIRE-22342 segfaults related to using OpenJPEG instead of the non-free version.  (Not OpenJPEG's fault; a problem in error handling.) That's been the show-stopper on self-compiling Firestorm for some time.

    Once that branch gets merged back into Firestorm main, which is at 5.1.4.55097, we should have straightforward 64-bit Linux builds again.  Waiting for this has been holding me back on working on velocity extrapolation at region crossings, which still needs improvement.

    Congratulations to everyone involved.

    • Like 4
    • Haha 1
  14. Moving models back and forth between Blender and Sketchup has to be a mess. Blender is a mesh editor. Sketchup is a constructive solid geometry editor.  CSG systems have real solids, not just faces. All CSG objects are "watertight".  Mesh to CSG is not likely to work too well, especially if the mesh isn't watertight.

    • Like 1
    1. How many "real users" (avatars who could answer a CAPTCHA if asked)  does SL really have on line at daily peak?
    2. Does LL have any serious plans to grow that number? The plans for 2018 seem unambitious.
    3. SL is far below modern video game standards in terms of frame rate, image quality, and movement control. What's the plan to get up there, to at least the level of High Fidelity or SineSpace.
    4. What's the plan for mobile?
    • Like 1
    • Thanks 1
    • Haha 2
  15. We've now driven 1000km with our test bikes. Results so far:

    • 1000.63 km driven.
    • 68.42 driving hours.
    • 5234 region crossings.
    • 25 clear "half unsit" region crossing failures.
    • 64 trips with "trouble" (see below).
    • Fastest trip over 10km: 54.59km/h. (Rachel Stardust)

    Leader board - Successful trips over 10km.

    +---------------------+--------------------+----------+-------------+
    | driver_name         | speed              | distance | trip_status |
    +---------------------+--------------------+----------+-------------+
    | Rachel1206 Resident |  54.59476223527404 |  15.6657 | OK          |
    | animats Resident    |  50.04449913300664 |   11.538 | OK          |
    | Rachel1206 Resident | 42.340414923148096 |  10.9615 | OK          |
    | Rachel1206 Resident | 41.240210008481924 |  11.7649 | OK          |
    | animats Resident    |  40.81029328697811 |  33.3964 | OK          |
    +---------------------+--------------------+----------+-------------+
    

    Distance is km, speed is km/h.

    We're ready to start planning some road rallies.

    (Getting caught in a ban line, running off the road and logging out, browser crashes,  getting disconnected, or simply logging out without getting off the bike first  all count as "trouble". A successful trip is when the driver had no logged problems and parked the bike at the end.)

    bikerezzer.thumb.png.10ded8dd475dbf5f6e2c0f41d5201884.png

    Our free demo bike rezzer in Kama City.

    Go take a test drive. Go anywhere in Zindra.  No time limit; the bike will disappear when you get off.

    • Like 2
×
×
  • Create New...