DilliDallagio

OP, I don't tend to visit survey sites due to the trackers and what-nots that are probably in use. If you care to present your suggestions here so all may be able to weigh in then I'd be happy to take a look. Signed, Just another tin-foil hat wearing conspiracy whack-o

Just a follow-up on current and future macOS support... Per Inara Pey's blog LL still plans on supporting macOS. They need to evaluate how to transition the viewer from OpenGL given that Apple made announcements about deprecating OpenGL and making the move to power Macs with their own custom silicon. https://modemworld.me/2020/07/11/2020-sl-project-updates-week-28-tpvd-summary/

You've articulated what I've been thinking. I think the keystone to this acquisition is Tilia. Whether or not the possibility of spinning off or selling Tilia was a primary reason to create Tilia way back when it certainly may have been a one of the focuses of the new investor/owners.

Perhaps there would be some issues but nothing insurmountable. OpenSim uses the concept of variable regions which effectively can make a region size up to 2048m x 2048m (maybe larger?). I've only personally experimented with 1024m x 1024m sized "varregions" on my own OpenSim standalone and the scripting seemed to work out of the box. Granted, OpenSim uses OSSL vs LSL, but the former is based upon the latter with the addition of special functions used in OpenSim. Again, may be some issues but not insurmountable. Yes, existing LSL scripts may break. Given the number of "abandoned" scripts present major usability problems. But new scripts written for the change in region sizes should present no problems. Having said that OpenSim has been unable to, at least in my experimentations, allow cross-border scripting to work with variable regions. At least I've not experienced the ability to be able to physically cross from one variable region to another on OSgrid (where there seems to be a boat load of these variable regions deployed).

Awesome! Hope that LL is taking notice. If this works, it could also mean the companion iOS application that LL is currently developing (at least in alpha stage now, if not some sort of beta) could becomre more than just an IM/Group Chat app.

Mac OS X (or OS X or macOS or whatever it is going to be called in future generations) never exposed the "compatibility" profile of its OpenGL implementation to version 4.x. When the viewer is showing the Mac OS to be at OpenGL version 2.1 or 3.0 (as in the case of my using High Sierra at the moment), that is the "compatibility" profile version of the Mac OpenGL implementation. The SL viewer run against the "compatibility" profile. When using a benchmark applicaiton on Mac OS X chances are it is showing the "core" profile OpenGL version to be 4.1 (which is that last standard that Apple bothered to achieve with its implementation). None of the SL viewers, whether they be from LL itself or any of the third-party teams, use OpenGL "core" profiles. Perhaps those that actually modify viewer code can shed some light on why "compatibility" profile is selected over "core." As many have pointed out earlier in this thread, Mac OS X really needs to have a viewer built against current APIs, such as Metal 2. I can understand LL's reticence in hiring the additional developers that will be necessry to build a Mac version for what seems to be a (very) minor segment of the SL residency, but barring that it seems unlikely such viewer mods/building will come to light. Now, add to it that by 2022 all future Macs will be running on Apple Silicon with ARM instruction sets instead of Intel/AMD x86_64 and it seems even more unlikely that LL will create two versions of the viewer. (Yes, I know about Rosetta 2 and the "demo" of Shadow of the Tomb Raider running on a developer kit of the A12Z Apple Silicon. Independent bloggers who have received the development boxes and conducted their own benchmark comparisons show that there is a big hit running an Intel-based applicaiton under Rosetta 2 vs running it on a native Intel box.) I love Mac products. They saved my professional skin in 1999 when I needed to get a media project done and the Windows PC I was using at the time was constantly Blue Screening. Running down to the local CompUSA and buying a Power Mac saved the day, I've been using them up to 2016 when I got so frustrated with SL performance on an iMac that I switched over to linux (on the iMac) and noticed incredible performance improvements. That's when I realized that the linux drivers at the time were exposing OpenGL "compatibility" profile to 4.3 and the viewers took advantage of it. Now in 2020 I'm back to running a Mac and SL performance suffers (the purpose built linux box suffered a fatal motherboard death and I've not yet replaced it). While I can hope that someday LL will create a viewer to natively run on a Mac, I'm not holding my breath.

Yes you can. My species of potato: Mac mini Mid 2010 Core 2 Duo P8600 / Nvidia GeForce 320M / 4GB RAM. Not sure what one would call that species but it is definitely a bit musty and squishy. According the UserBenchMark, the OP's choice of GPU is 1000+% better than mine. If I can log in and fumble about (just have to avoid groups of avatars that are 2 or more in number... no biggie) then they should have no problem fumbling about with better visuals than me.

A single "thumbs up" for the finds, Whirly. If those images were taken where I think they are, two "thumbs up" if you can get one of Oz in the sign.

With the help of network specialists, I think I have the missing rezzed objects thing taken care of. Basically, even though my network connection has plenty of bandwidth, there is some serious ping times involved, especially when it my viewer(s) are trying to make connections with LL's Akamai CDN servers. They suggested some debug settings changes which seem to have helped most of the missing rezzed object problems. As for the thing with worn attachments that are invisible when not being edited... still working on that.

This! During my experimentation there was a visible difference among the three viewers I use when it came to rendering the physics. Each was different, and in not so subtle ways. Also, what looked good in my lag-free apartment did not look so smooth down on the ground with less than 20 FPS. So not only are physics calculations viewer side, I guess it also depends upon the viewer itself.

Well, I checked the FS wiki page as suggested and all my viewers' debug settings were already set to the default. I dropped my network bandwidth down to 200kbps, and though things take longer to download, that did not help. Still getting the same "missing textures" and "wire chewed by rabbit" error messages in the debug console/log. The same items rezzed on land still disappear unless I right-click in the emptiness where they should be or I use the viewers' equivalent of reset vertex buffer/reload displayed objects. In some cases that does not work so I relog and that mostly works. As to the problematic worn tentacles, when rezzed on the ground they are visible. When worn they are not. If I edit them while wearing, they are visible but as soon as the edit floater is closed, they go invisible again. None have scripts and up until a week or so ago I did not have this problem with them. I guess it is SL just being SL?

Having spent a good deal of time today playing with physics, I have learned that Altamura's butt physics are not very flexible. One has to almost max out many of the settings on both the "spring" settings and Advanced. Even then the effect is subtle more than pronounced. They also do not work in the same way as they do on the classic avatar. Butt sway does not mean the entire buttocks swing side-to-side. Instead, the inner and lower butt cheeks, along with the inner thighs swing. The same goes for butt bounce. So it is more like a subset of the entire buttocks that moves rather than the entire construct. I guess that is so people can wear Maitreya Lara mesh dresses and skirts that may not have been rigged for butt physics without having their butts clipping through the garment. (Removing the Altamura body reveals a very gelatinous classic avatar though, for what that is worth.)

Done experimenting. What I have seen is that by using a physics layer to approximate natural gravity-fed shifting is hit or miss. How effective the physics is depends upon pose, angle of camera, lighting, etc. Physics layers of varying settings can be useful tools, but they almost have to be customized for each pose... provided there is enough adjustment to accommodate the desired pose. What I also learned is making physics adjustments to work on static poses means they are horrid for normal, everyday walking around use or dancing.

How very nice. Maybe we should send our physics over to you for some critiquing?

hehehe... I already had when you posted it earlier. I just have not gone out into the wilds to see if it made any difference (working on avatar physics at the moment). But I will.