2019 TPVD meeting week #40

10 thoughts on “2019 TPVD meeting week #40”

1. Is there a reason the BoM update of Firestorm wasn’t included? It was definitely out in time for this meeting.

   LikeLike

   1. I tend to focus on the Lab end of things with these meetings, and offer an update on changes to the Lab’s pipeline of viewers. This is for three reasons: the Lab’s list of viewers is smaller and so doesn’t read like a litany of viewers 🙂 ; secondly, this meeting in particular is more about updating TPVs about what is coming down the pipe from LL, rather than an open discussion on TPVs themselves; finally, some TPV coders get their knickers in a twist if I mention X but not Y. Instead I leave TPV updates to my main viewer release page and the weekly summaries.

      The Firestorm release is covered here, however: Firestorm 6.3.2 Welcome to Bakes on Mesh.

      LikeLike

      1. That works. 🙂

         LikeLike

      2. “finally, some TPV coders get their knickers in a twist if I mention X but not Y.”

         Was that aimed at me? I sure hope not because i can’t remember complaining about it before.

         LikeLike

         1. Someone appears to have a guilty conscience…! 😉

            LikeLike

            1. Um yea because that’s exactly the kind of thing i’d do. Still though i can’t remember ever doing it (here), pretty sure i complained at Nalates once for reporting only about Firestorm and basically purposely leaving out other Viewers. Which has ultimately lead to me reading her blog less.

               LikeLike

               1. I will put you out of your misery and say the reference I made did not include you. And that is as far as I’m going.

                  LikeLike

                  1. Well that’s something.

                     LikeLike

2. Thank you so much for keeping us updated! I am looking forward to all these new features!

   I have a few ideas of what they could offer super premium platinum members although none of my ideas apply to creators.

   They should have a a premium status specifically for creators and focus on perks that would help creators speed up their workflow, save money on uploads, etc.

   Lower upload fees would be great!

   The ability to own a private sim on the beta grid 🙂

   I understand why 1024×1024 are the max but what if we could upload 8192 x 128 pixels too! (same number of pixels) ((I have my reasons))

   Allow elite members yo upload 2048×2048 images for 50L a pop?

   Allow super premium members to upload temporary mesh on the main grid that lasts until you log out or a set number of hours have passed.

   Allow more detailed “Linden Dollar Transaction History” on the second life website. For example, when I send an object to someone, in their transaction history, only shows this info:
   Detail Source: Ample Clarity – Give Inventory
   Debt: L$0

   Multipartners for polyamorous types. Had to throw that one in there.

   Allow elite members to search through years of transactions.

   The ability to buy something in-world but have it delivered via the marketplace (similar to caspervend). This would be especially helpful because of the new marketplace redelivery feature for those of us who like all sales data to be in one format and in one place.

   I would love it if premium/super premium members could have a blue tick next to their name (like Twitter) on the marketplace and inworld to indicate your verification status… although having the ability to have a last name does add some credibility as a merchant, especially for those new accounts.

   Offline messaging tool similar to zendesk with built-in bot and auto-reply AI.

   Tiny private sims 1/8 size sims or 1/4 sims.

   Edit animesh with sliders. Give animesh body physics. Animesh profiles (similar to avata profiles but specifically for animesh)

   Oh gosh, I really do hope the Lindens read this!

   LikeLike

   1. Interesting ideas, but without wishing to pop any of them too much:

      Premium levels (and just for clarification, give you use several different terms of premium levels): as per 2019 Web User Group week #40: Name Changes and new Premium option, these is only ONE new premium level, “Elite” that has to apply to all.

      Textures: this issue isn’t size of textures, it’s memory use and rendering:

      • Memory use: the default for texture memory use tends to be 512 MB or 1 GB; a 32-bit 512×512 texture occupies 1 MB; however, a 32-bit 1024×1024 MB texture occupies 4 MB, and a 32-bit 2048×2048 texture would occupy 8 MB – so larger textures can quickly eat up available texture memory, particular for those on older systems where their texture memory use is more heavily bounded.
      • Rendering: there is already a tendency for some users to use higher-rez textures (512×512 and 1024×1024) on every surface / face, no matter how small, because of the believe “higher rez is better” (even in places where no-one would see the difference unless *really* zoomed in – and even then it might be doubtful). Thus, we already have an issue with high memory use *unique* textures appearing in a scene (shoelaces here, buttons there, a string of lights, a cigarette packet, etc.), clamouring for texture memory space – upping to 2048×2048 could exacerbate that.
      • (As an aside, textures up to 2048×2048 can be uploaded, but anything over 1024 on a side is downsampled at upload).

      Temporary mesh uploads: I assume this is for testing purposes – which is really what Aditi (the beta grid) is for (although access and space can at time be iffy). Temporary on Agni (the main grid) introduces complexity: how should temp mesh be flagged? How is it tracked (What if I upload a “temporary” mesh in my workplace in my work space on region “X”, but then opt to go to region “Y”, where it will eventually be placed, and upload another “temporary” version there – ant then leave both out “for the system to take care of”?). What kind of audit trail is required to track such “temp” uploads again a user being logged in or out? What mechanism / safeguards need to be built in order to ensure when removing uploaded “temp” mesh, other mesh also uploaded in the same period by the same user isn’t accidentally deleted?

      Purchase in-world for delivery via the Marketplace: this would require a dedicated API that vendor makers would have to hook into, some of whom as you note, already provided their own redelivery mechanism. So the questions here are: what kind of work is involved in providing an API and how would vendor creators respond to a) using it; b) having their toes somewhat trodden on by having the Lab “moving in” on their work.

      “User verification”: two points here:

      • Beyond placing payment information with the Lab (which any Basic user can also do), Premium isn’t any kind of formal “verification” process – it is simply a means for users who choose to do so to pay for their SL membership. Arguably, creators who have Basic accounts and who cash-out from Second Life are “more verified” than many Premium members who are not creators, simply because they have had to provide documentation to LL formally identifying themselves.
      • “verification” implies some form of formal vetting of a user – which again, paying for a subscription membership really isn’t. So while they are nice, little blue ticks on profiles, etc., can be misunderstood – such as being taken as some form of “endorsement” of one group of users over another by the Lab, leading to all kinds of possible complications LL would want to avoid. In this regard, I would point out that in November 2017 Twitter actually suspended its own account verification process precisely because of the issue that “verification” can be misunderstood as “endorsement” – see: Twitter suspends account verification, and that suspension remains in place today, almost 2 years on.

      “Tiny sims”: the only way this could be done for the foreseeable future is via parcel sizes and “free” tier (the 256×256 region size is too deeply baked into SL’s architecture to allow different sized regions). While not beyond the realm of possibility (offering more “free” tier for people’s $ wouldn’t be that hard to do vis-a-vis Mainland), LL also need to keep a wariness around appearing to be competing against private estates (which are still their revenue bread-and-butter).

      Animesh: there is already a project underway to extend this – Project Muscadene, see my CCUG summaries. This doesn’t current encompass body shapes / sliders, but that has already been put into Muscadene for future consideration. More particularly, this kind of work doesn’t really lend itself to just subscription-based users, rather it is extensions to projects that can only be made available to all, simply because of the UI considerations (how, for example, do you ensure that only “Elite” members can manipulate Animesh body shapes (assuming they are added) via the slider system? Remember, the viewer is almost entirely open-source, so isolating functionality isn’t that easy).

      LikeLike

Comments are closed.