2019 TPVD meeting week #40

Clifton Forge, August 2019 – blog post

The following notes are taken from the TPV Developer meeting held on October 4th, 2019. A video of the meeting is embedded below, my thanks as always to Pantera for recording and providing it. This was a relatively short meeting, with the majority of the meeting conducted in text and revolving around Bakes on Mesh. This being the case, points are summarised below without the usual time stamps.

SL Viewer News

There have been no further updates to the official SL pipelines since the updates at the start of the week, leaving them as follows:

  • Current Release version 6.3.1.530559, formerly the Umeshu Maintenance RC viewer, dated, September 5th – No Change.
  • Release channel cohorts:
  • Project viewers:
    • Legacy Profiles viewer, version 6.3.2.530836, September 17th. Covers the re-integration of Viewer Profiles.
    • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.530473, September 11th.
    • 360 Snapshot project viewer, version 6.2.4.529111, July 16th.
  • Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29th November 2017 – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Brief Notes

  • As noted in my recent CCUG summaries, the Lab have recruited two more graphics experts (Euclid Linden and one other), who will be working on EEP and rendering projects once they are up to speed.
  • The new Voice update viewer should be going to QA in week #41 (commencing Monday, October 7th). This was delayed as a result of a last minute issue preventing it going to QA and then being issued this week.

Bakes on Mesh (BoM)

There is reportedly some confusion about Bakes on Mesh, with some users believing it means that “have” to switch back to using system wearables. This is not the case; those who wish to continue to use applier-based wearables can do so. Similarly, those who prefer to use mesh clothing can continue to do so. Bakes on Mesh is simply a means to allow system wearables to be used on mesh bodies and heads.

It is also hoped by the Lab that BoM will allow mesh head and body makers simplify their products by removing the need for some of the “onion” layers. This should reduce the rendering complexity of bodies and heads, making them less resource intensive to render.

For more detailed information on Bakes on Mesh, please refer to the following links:

Linden Lab:

Creator-related BoM documentation:

Informative Bakes on Mesh blog post:

In addition, Firestorm has created their own Bakes on Mesh wiki.

TPV Notes

  • Catznip has a BoM beta (and has done for a while), but release is pending some more work being completed.
  • Radegast is close to having a BoM release available.

10 thoughts on “2019 TPVD meeting week #40

    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.

      Like

      1. “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.

        Like

          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.

            Like

  1. 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!

    Like

    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).

      Like

Have any thoughts?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.