Coffee Pancake

Suck it.

It's been a number of years since I used Rhino .. it's certain a very capable, but perhaps not really suited to real time content, the models it creates can easily be very high poly.

Damn ... depending on activity on his land (as some rezzors are set to only fire up if there is a nearby avatar). He's rezzing between 320 and 660 temp prims every 20 seconds on a parcel that only supports 702 actual Li. How can this be ok? If it's ok, why aren't I doing it !!! He really should own more land.

Would appreciate if you could drop a copy on me in world Phil.

As the number of seconds it takes to login is obviously the high stakes deeply important take away issue from this thread, might I take this moment to point out reading this reply took longer than the difference in load times. Generally we tell people to leave the viewer files alone and go the KARA sim (seriously, that one is gold .. and easy to remember) and relog. KARA rules out any locational weirdness and the relog resolves all issues .. 90% of the time. The trouble shooting options we provide are more about giving those inclined to busy work something predictable to try before they get frustrated and ask for help. You wouldn't believe the crazy lengths some people will go to attempt to resolve an issue. It is quite possible to tinker with debugs or viewer files and completely break the client and that's actually a lot harder for us to support, not to mention very time consuming. When I have followed up inventory issues personally (guess what I spend my days in SL doing) .. it's an unstable connection 99% of the time. If there was something solid and repeatable we can fix .. it just gets fixed. That would be exactly how Kitty's inventory was 'sorted' prior to the recent shopping related auto sorting ... (and incidentally why you can search inventory with regular expressions) ..

He intentionally sticks to vintage prim based content to avoid this gotcha ... and I can't convince him of anything, he banned and blocked me the day he moved in.

Plenty do actually believe that an unsorted inventory (or worse) causes lag. I'm just thankful it's impossible to see how much inventory someone else has ... that would be a drama nuke. Actual inventory loss is exceptionally rare and can only be corrected by filling a support ticket. He really shouldn't do this, especially for no-copy items. Should his box fail to rez then it can be permanently destroyed depending on the cause of the rez fail and if it's caught by the region.

(mainland) Our neighbor is making excessive use of them with several rezzors producing hundreds of objects on a 20 second loop spread over half a dozen builds on his plot .. literally everything he could put in one is in one (if not floor...temp!). "free sex" skyboxes with only 9Li of static content and 80 Li of temp content. Everything in his multiple stores that isn't a vendor. A floating art gallery shop in which the only static content is the floor, and so on. The rezzors zip around his builds for no reason other than to hide their existence and he is fully aware that they are bad (to the point of getting paranoid when some Lindens showed up to test a region crossing issue I had reported) ... but he's a "srs biznss man" so that must make it ok, somehow. The region is less than half populated and the script time is maxed out. Multiple abuse reports from more than one of his neighbors ... and they are all still there. Seems LL believe their built in limits are satisfactory (they aren't) and unless the region is actually tanked and on fire aren't prepared to do anything.

How you "organise" your inventory has zero impact on how it loads into the viewer or how much lag it may or may not cause. Organising your inventory is for your own personal benefit, the computers involved (yours and SL's) don't give a toot. A truely massive inventory can cause some issues, but we're talking an insanely large number .. say 7 figures. We (Catznip developers) are shopaholics with @Kitty Barnett having the largest inventory I've ever encountered owning literally everything she has bought since she started SL, it has no impact, don't worry about it. (If it did, we would have fixed it already). The single biggest inventory related issue we find from our users is a poor internet connection combined with a lack of patience and frustrated futile attempts to "fix" the issue by clearing the cache, reinstalling ... and worse. If you have inventory woes, check your connection. Reboot your PC and your router .. leave it off for a few minutes. Use a wired connection rather than wifi ... if you must use wifi, move some place else or adjust your antenna. Close your web browser and don't minimize SL while you wait. Be patient. Find and landmark a nice quiet water sim (like KARA) and log in there when you have issues you can't resolve yourself. Don't panic. Don't worry that all your stuff is "gone" and don't start setting your viewer install or computer on fire in some blind misguided attempt to make it work.

I just need to move my neighbors naughty box....

I quoted 16Gb for several reasons. Any laptop shipping with that amount of ram will come with a decent CPU and GPU, immediately cuts the number of options down. Windows 10 .. kinda needs 4GB to get out of bed .. and will happily eat another 2 with buffers and cache (and prioritize that over running applications!). 8Gb is tight and bottle necks fast. Typical use-case is running SL and a tabbed web browser at the same time. People complain about SL performance all day, but they wont even think about closing chrome.

Exceptionally high ARC avatars tend to be those with older flexi attachments such as skirts, hair and wings. The only thing Jelly dolls "protect" you from is the rendering of the avatar in question, the viewer still downloads all attachments etc. With everything working as planned, the render cost of a jelly doll willl be lower than the original avatar, although this is not always the case . ARC is a very imperfect measurement. I would say an arc of 1.5 million is an edge case where the avatar is being punished excessively for older content and does not represent it's actual render cost. You also do not have to worry about overheating causing damage to your PC parts. Your CPU and GPU will automatically throttle back long before they are in actual danger and can run quite happily at high temperatures. Both of which have large heatsinks (etc) specifically designed to dump in excess of 100W, keep them dust free and you wont even be able to get them to thermally throttle no matter what you throw at them.

Onion skinned mesh bodies contain several copies of (almost) the same mesh layered like a Russian doll. Multiple mesh layers enable each to have a different texture applied ... skin,tattoo, underwear & clothing. They are a terrible hack to get around some of the limitations of SecondLife and objectively bad from almost every technical and performance perspective. What we really want (DESPERATELY) are script functions from LL that would allow a list of textures UUIDs to be merged into a single texture that can then be applied to any object.

Yes. that is the idea. You will need a updated body that sets the baked flag, then all your legacy linden clothing can be worn and be applied to one layer of that body. Will it look any good .. eeeeehhhh maybe.. YMMV When released will allow for higher resolution image maps in linden clothing items, so newer stuff will look much better that all the legacy items you have. The main uptake from all this is that those legacy clothing inventory types will be back from the dead.

If you're going to play SL on a lappy then I have one word. RAM 16GB or move on Laptops with reasonable amounts of memory as shipped new also tend to have decent processors and graphics,

I'm more of a GODOT girl Oh no, being able to nuke lower LODs to nothing is really good .. for indoor items. SL's rendering isn't great at working out what can't be seen, so having objects dissolve to a single tris per face is the best possible outcome for small indoor objects, if you're not in the same room as them, they are as light as it's possible to make them. It's annoying to have outdoor stuff just pop into existence and vanish just as fast but it's certainly not bad for performance. Sometimes it just takes a little more creative placement. It's more annoying when furniture items have been uploaded with the mesh decomposition tool set too aggressively for intermediate LODs and items go from fully formed to poly-spaghetti (please cheeky pea .. stop doing this, I love your stuff, but it's universally terrible and not fit for purpose). Personally, if something is being sold as no-trans, then there is no reason creators couldn't include multiple versions with differing LODs and letting the end user pick the one that best suits it's use. Although .. hand building the intermediate meshes is the ideal solution.

I'd really like to see per face texture post processing added and set up so that it could be changed even if the object was no-mod. Being able to adjust the brightness, saturation, etc would go a long way to allowing creators to step out of the shabby-chic box because items could be matched to each other and their setting.

In SL's case, realtime shadows doubles* the poly count. While this doesn't doesn't double the GPU load it does slow things down some; assuming you have slack capacity, which with a 780, I do ... if you're on a lower end or integrated card, shadows can easily push you beyond your GPUs intended load and bring SL to it's knees. My suggestion about poly counts and the mesh uploader is mainly about favoring content that actually degrades cleanly rather than raw poly count, Objects popping out of existence or turning into a wonky mess is the core motivation for jacking the LOD slider in the viewer to the max regardless of hardware (less than max isn't usable). Allowing the existing LOD features of SL's render engine to work as designed would go a long way to keeping SL running on the majority of lower end hardware. Screenshot with Ktris** with and without shadows .. * The doubling isn't a literal doubling of raw polys, it's technically multiple render passes for each shadow casting light source and cheaper than the primary render pass due to differences in texture handling. ** it's showing a little higher than double as this is SL and I didn't take any steps to isolate myself from others on the region, so the diff is probably @Kitty Barnett arriving between snaps at double her raw poly count This is not quite the same as baking shadows & lighting into textures. Texture re-use died with prims as every mesh asset now has it's own dedicated UV painted map, it's pretty safe to say that the days of buying a texture and slapping on half a dozen things are long dead, so in that sense as everything has it's own texture, there is nothing bad about baking lighting onto it .. aside from the baked lighting needing to be fairly neutral. Objects needing multiple maps in order to maintain resolution makes a solid case for 2048 or even 4096 texture maps as every face of a single object sharing the same map can be drawn in the same batch. SL's woes can not be boiled down to a single overarching factor, like raw VRAM usage, more that the engine was designed for a specific content type (prims) that has been for all intents and purposes superseded. There has also been precious little evolution on the render engine since the last iteration years ago, mainly because LL need to hire more wizards.

If there was a way to automatically generate good LOD meshes on the fly with a user selectable bias, I would say dump the existing mess in a heartbeat, delete all existing auto-generated mesh LOD models and let the client figure out the magic. Till then, I'd like to see some hard actual numbers from LL as to what LOD meshes should contain and some basic tutorial content. For example each LOD needs to have 30% of the polys as the previous level AND provide a substantially reduced Land impact to people who manually create all of the LOD levels meeting those guidelines. No bonuses for using the built in decomposition tool and set a minimum Li of 5 for everything that isn't 100% manually created.

Nothing quite like a bulging friends-list of people you cant't message to really hammer home personal isolation.

I believe the opening 'axe riddle' scene from 'John Dies at the End' sums up how software development works. ( I cant post it here as the film is R rated and the section in question somewhat gory) .. one of my favorite films. Needless to say. There has never been a blank slate development of a new viewer since the very first one. Most of the time changes are small and obviously incremental, other times, huge chunks are replaced. Keep in mind .. what you understand as milestone releases are simply when key visual elements changed.

I love the impact SL creative freedom and the people who share in it have had on my life. changed my whole world. I have a list of hundreds of things .. but really, if I can only pick one ... CLIENT SIDE AUTHORITATIVE PHYSICS

Spoiler alert ... That's not how viewer development has ever worked.

Adding multi-threading to an existing application is hellishly difficult if not impossible, there might be some low hanging fruit to try, but the results are not always what you might hope for. Applications need to be designed to be multi threaded from the ground up.

SL Go was a remote rendered streaming solution .. and no one wanted to pay a monthly for it. SL Go did roll some basic UI stuffs to allow the viewer to be controlled via a touch screen easier. but thanks to a technical loop hole in the licence they were not obligated to share their changes with the OSS viewer community. .. as an alternative, you can add the SL viewer as game to Steam and then use home streaming to send SL to a mobile or lower power device.