animats

I dunno. I'll probably turn it off in the viewer if small parcels start having their own sky. Too annoying as you move around.

If you want files from which you can make .dae files, there are many 3D sites where you can get them free or buy them. But they will usually have too many polygons for SL, and they won't be directly compatible. So for anything non-trivial, you have a lot of work ahead of you.

Why? Because doing it right is a lot of work, and the tools are weak.

Yes. SketchUp is a constructive solid geometric (CSG) modeling system. Most modern engineering design programs are like that - SolidWorks, Autodesk Inventor, Fusion 360, TinkerCAD, FreeCAD, etc. Those are the tools you use to design real world buildings. All primitives are volumetric, and you get operations like union and intersection by default. Second Life wants surface meshes, because it feeds them, with little modification, to OpenGL, which wants surface meshes. Most of the CSG-based programs will export meshes, but that's a sideline for them, so they don't have tools for mesh reduction and level of detail. Their real purpose is often to generate tool paths for machine tools, and the smooth surface you design in the CAD program had better come out smooth when you cut metal. So you get too many triangles in the meshes they produce. This isn't a fundamental problem with CSG; it's a consequence of the asset pipeline lacking a smart mesh reduction stage. The major game engines have asset pipelines which allow mesh optimization between the artist and the game asset. SL lacks that, except for a terrible mesh decimator in the mesh uploader. (More smarts there would help a lot.) Blender makes you deal with raw surface meshes. This is a pain, but you're operating at the same low level Second Life operates at, so you can optimize meshes manually. There are also lots of tools and add-ons for Blender to muck with meshes in various ways. Productivity is low, but good work is possible. CSG with automated mesh optimization and generation of bump maps and normals for fine detail is what you probably really want. More user-friendly. Sinespace seems to be going down that road.

I sell a few things for L$10. These are mostly little things I developed for my own use and would be willing to give away, but I sell them for L$10 to keep down frivolous requests.

The Unreal Engine 4 benchmark "Valley" is a good system and graphics test. It's a stress test for graphics hardware.It's a 5 year old benchmark, so it doesn't require extreme hardware. It demands far more from the GPU and system than SL does. Let it run for a while, like an hour. If there are no problems, your GPU is working fine and your whole system probably is. It's pretty, too. It displays a large and beautiful outdoor world, equivalent to 1024 SL sims. By default you're shown a standard tour, but you can take over control and walk around.

Agreed. We can only see dimly here, because there are server side problems and we can't see into the servers. We can look at OpenSim, but it's internals are completely different. (OpenSim is written in C# and uses TCP for sim to sim communication. SL is written in C++ and uses UDP for sim to sim communication). We can look at message logs, see things happening out of sequence and causing trouble, but can't tell whether the sim sent them out of sequence or they became out of order during transmission. The idea here is to nail down some of the variability so that some problems are solved and others become more clear. This should turn what is now a really hard problem into a succession of not so hard problems. This is like peeling an onion. When I started, there were a whole range of unsolved problems at sim crossings. Some I've been able to work around in LSL. One required a fix in Firestorm. I've produced bikes that drive well over region crossings. Each fix peels away another layer of problems obscuring the deep problems that cause sim crossings to fail outright. We're getting closer.

New update to BUG-214653. Not a fix yet, but an approach to one. If you've been inside the viewer or really understand the message system, take a look. I've been putting logging code into Firestorm for object updates and watching region crossings go by. The built-in logging doesn't show object updates in detail. I have lots of message logs, some annotated. Here's a detailed log of a successful region crossing, with an explanation. If you ever wondered what was happening down at the message level, here it is. Region crossings which have this sequence of events work fine. If the message sequence deviates much from this pattern, things go bad. At the viewer object level, there's a hierarchy. The root of the object sat on (in a region crossing, usually a vehicle) is the root parent. The sat-on object's prims are its children. The avatar is a child of the object sat on. The attachments are children of the avatar. (Yes, the hierarchy here has three levels.) If the object updates arrive in the viewer in vehicle-avatar-everything else order, all is good. If something arrives before its parent, the viewer tries to cope. But it's difficult, and things can go wrong when the pieces are spread across two regions and several coordinate systems, some of which are not fully defined yet. This is the source of giant jumps and snap-backs at region crossings. It's the source of the visual mess where you cross a region boundary and some attachments and vehicle parts disappear for a while. And it's part of how attachments get lost. If the messages are delivered in the normal order, everything works. So the update to the JIRA is about how to do that. It won't fix everything. But it will fix some of the problems and make the remaining ones far less mysterious and unfixable. "This is not the end. This is not even the beginning of the end. But it is, perhaps, the end of the beginning." Churchill.

Online therapy is a real thing. But read "What you need to know before choosing online therapy", from the American Psychological Association.

Are you trying to implement a game with crafting? The kind where you collect 3 Iron, 1 Brass, and 1 Wood, and you go to a Level 7 Smith, and he puts all the stuff into a Forge, and you get a Sword out? That can be done within SL. Some of the SL farming systems have something similar, where you harvest crops, do things in a kitchen, use an oven, and food comes out.

LIFE properties has a lot of land for sale in Zindra around $7/m^2. Nobody is buying.

Despite what it says here, it looks like only Lindens, and the 57 users listed as "helpers", can edit the wiki.

I'm not sure what he wants. A customizable user interface, I think, so you could make the viewer look like a specific game. That's an interesting idea. You could try doing that with HUDs. You can do a lot with game-specific HUDs. Drivers of SL has some good ones. Try prototyping it that way and see how far you can get. Get some user experience with your proposed user interface.

I can log into the SL wiki, but it says I don't have permission to edit my own profile page there. Is the wiki still editable at all?

Firestorm on Linux handles this problem very badly. It manages to jam up the entire window manager while stuck trying to log in.