2019 Content Creation User Group week #46 summary

Kinglet Sound, September 2019 – blog post

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting held on Thursday, November 14th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are available on the Content Creation User Group wiki page.

Environment Enhancement Project

Project Summary

A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will now likely not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

  • Merging with the last set of viewer releases has caused issues, and these are currently being addressed.
  • Beyond the above issue, clearing the remaining EEP bugs is “a priority focus”.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

  • Vir is working on providing a means for data collection across a range of different viewer-side hardware specifications.
  • His previous work on textures and texture handling / loading have revealed it is hard to quantify in terms of accounting for performance impact, as textures don’t result in the same kind of impact as mesh triangle complexity.
    • With mesh, there is a clear complexity correlation between the number of triangles and performance /  complexity hits.
    • The number of textures on a object don’t behave the same way, other then during initial loading or if they push against memory limits, so, there’s no gradual degradation in performance with texture that can be seen with mesh, making it harder to produce accurate calculations.

Avatar System

The avatar system has become considerably more flexible over the years, but also far more complexity to use. Given this, Vir put out a question on whether there is anything creators would like to see Linden Lab do in terms of managing the avatar behaviour and configurability.

For example, one aspect of avatar system management is HUDs, which can be impactful in a number of ways  – resources simulator side, texture use viewer side; general ease-of use. Discussion on this raised some suggestions ideas:

  • Presenting them through (if possible) a dedicated floater in the viewer that could be dragged around like any other floater, minimised, etc.
  • Possibly extending llDialog to prove better support for HUD-like actions via dialogues.
  • Providing an HTML-based means for HUD-style interactions.
  • Having a “favourites” inventory folder sub-set, floater and toolbar button, a-la Firestorm that users could use for their various HUDs and (hopefully) encourage them to only attach (via the toolbar button / floater) when required – thus assisting with reducing VRAM usage for users / eases resource loads when avatars move between simulators. This idea has been discussed at the Lab.

A further discussion on this involved avatar shapes and applying / managing parameters.

  • Currently the body shape is a “container” for all body parameters (head shape, body size, leg length, torso dimensions, etc).
  • This can make it hard when trying to carry out localised modifications to a part of a body (e.g. applying head parameters to a “preset” shape designed for a specific head brand).
  • There have been suggestions to help improve this, including:
    • Providing a means of exporting specific shape parameters for making new body shapes (see feature request BUG-216131).
    • Manipulating the shape via LSL (not seen as necessarily user-friendly).
    • Having some form of wearable that can be associated with specific body area parameters so that when used, would cause the currently worn body to adopt those parameters.
    • Provide a means to support some kind of “mask list” that just governs which bones they affect. This would allow for quite arbitrary sub-sets (as defined by the shape creator), but is seen as not that user-friendly, and potentially introducing added complexity into shape manipulation.
  • Some of these suggestions have a potential hit with increased UI complexity, but the idea of having explicit sub-set of shapes (e.g. one for the head, one form the upper body (or torso), etc.,) that have an obvious link to the sliders they would affect / be affected by, would seem to be the easiest for users to understand.
  • To address the head issue noted above, the most direct solution would be to separate the head shape from the body.

Other Items in Brief

  • Rider Linden is working on the texturing download and caching updates for the viewer, but these have run into merging problems with the current release viewer, so there is nothing available for public consumption on this work.
  • Several creators have noted issues with Bakes on Mesh and the left arm / leg, Universal wearables, tattoos and skins (see this forum post as an example, together with this feedback thread post). No precise solution has been offered (there has been a suggestion for LL to provide a means to convert existing skins to universals for left arm and left leg, but it’s not clear how well this would work in practice).

2019 Content Creation User Group week #43 summary

Breath of Nature, September 2019 – blog post

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting held on Thursday, October 24th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are available on the Content Creation User Group wiki page.

SL Viewers

Pipeline Updates

The Copy / Paste project viewer adds buttons for copying the X, Y, Z co-ordinates for the Position, Size and Rotation of an object to the official viewer’s Build / Edit floater, offering a similar capability to that provided by TPVs

The Love Me Render RC viewer updated to version 6.3.3.532031 on Wednesday, October 23rd, bringing it to parity with the current release viewer. The rest of the viewer pipelines remain as follows:

  • Current Release version 6.3.2.530962, formerly the Vinsanto Maintenance RC viewer, dated September 17th, promoted October 15th – NEW.
  • Release channel cohorts:
  • Project viewers:
    • Copy / Paste viewer, version 6.3.3.531844, released on Monday, October 21st.
    • 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.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

  • Vir is working on trying to gather data on the impact of textures in rendering avatars and objects.

Project Muscadine

Project Summary

Currently: offering the means to change an Animesh size parameters via LSL.

Current Status

  • The server-side support or Muscadene is awaiting an update.
  • The viewer has been merged up to the latest release viewer (no actual updates to the Muscadine code), and is awaiting QA testing.

Environment Enhancement Project

Project Summary

A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will now likely not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

  • The anticipated viewer update has been delayed as a result of a couple of the changes made resulting in unintended outcomes whilst in testing. Plus the viewer now needs to be merged up to the current release viewer.
  • Still no back-end updates while Ptolemy and Euclid continue to get up-to-speed with the SL rendering engine and pipelines.

Other Items in Brief

  • BUG-227585 “[BOM] Display the new Universal wearables between the Skin and the Tattoos ones” is a feature request suggesting the new Universal Wearables for Bakes on Mesh be moved from sitting above the skin and tattoo layers, to being between them.
    • With a noted reservation that doing so will change behaviour so are already using, the Lab has accepted the idea as something they might consider.
    • The Jira includes additional discussion points  / ideas.
  • The meeting included a discussion (voice and text) on alpha sorting and the issues that can occur within it when using alpha blending. Some of these issues are SL specific, others are more generic in nature and found within OpenGL in general. The suggestion was made to allow a certain amount of creator-defined ordering with objects, but there were several concerns raised around this by creators and the Lab, including the potential for performance impacts.
  • The above discussion spiked into one about avatar meshes, the potential for a new “standardised” (or “Lab-driven) “mesh avatar 2.0”, that could be far more rendering efficient than all existing models, th pro (better efficiency of design and rendering) and cons (whole new system incompatible with existing heads / bodies & getting people to use it).
  • Also folded into this was a conversation on how to encourage creators to make more efficient content.
    • One suggestions is to have some form of “scoring” system taking into consideration item complexity, use of textures, etc., that determines how high up on Marketplace searches goods appear & thus are likely to be seen and purchased – the idea being that by trying to “game” the scoring system, creators produce better content.
    • This skips the case of items sold in-world (how are scores enforced on vendors?). And also has a problem of how does an automated system “score” pre-packaged items uploaded to the MP (since it would only be able to assess the packaging, not the content)?
    • Alternatively, Vir pointed out that there is a lot more that the Bake Service could do in assessing the complexity of avatars in-world, and this could be potentially more meaningful in the future as ARCTan progresses beyond the current scope of the project.
  • Overall, and given the amount of legacy content in SL, one of the core ways of encouraging better content  is seen as not only making improvements to the mesh uploader and trying to push creators into making more efficient content – but to give users the tools and reporting that help educate them about what is going on around them, what is causing potential performance issues and then allowing them to start making more informed decisions on how they set their viewer and the kind of content they purchase.
  • Date of next meeting: Thursday, November 14th, 2019.

2019 Content Creation User Group week #42 summary

Summerland, August 2019 – blog post

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting held on Thursday, October 17th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are available on the Content Creation User Group wiki page.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

  • Data gathering is continuing, with the intention of gathering enough information on different rendering operations to be able to update the current cost coefficients being using in the rendering cost calculations.
  • Normalising the settings across different client-side hardware is seen as a challenge.
    • One thing the Lab proposes doing is running the resultant model across a range of client hardware types and different ranges of settings.
    • However, if there are significant differences across hardware types (which is likely), then some weighting mechanism will need to be used.
  • One issue noted as a part of the work is a persistent spike – frames in every second that were much longer than the others in the Windows viewer. This was traced back to a call being made to an expensive API that wasn’t even required and has therefore been removed.

Environment Enhancement Project

Project Summary

A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will now likely not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

  • The viewer is being merged up to the latest release viewer (version 6.3.2.530962, dated September 17th, promoted October 15th). This may also include at least one UI issue fix as well.
  • There are no further simulator-side updates that are ready for deployment as yet, but work has been continuing in resolving bugs.

Other Items in Brief

  • Following on from the discussion at the previous meeting about object size and land impact calculations a feature request – BUG-227762 “Removal of Size from Land Impact calculation/Texture LOD/Adjustable LOD distance” – has been submitted, and has been accepted by the Lab for consideration
    • The Jira also touches on texture management and handling, suggesting a way the textures for an object could be manipulated / downscaled in real-time.
    • It was pointed out that Firestorm offers an automatic downscale of 1024 textures in its 32-bit versions (and the setting in optional in the 64-bit versions), but the suggestion is that be providing users with information in the viewer could allow them to make more informed choices when making adjustments to help with their own performance.
    • This JIRA will be looked at in reference to ARCTan.
  • Something of a companion idea to this would be to allow a texture upload to produce multiple versions of a texture (e.g. a 1024×1204 also produces a 512x512x256x256 and 128×128). This has been discussed in the past, and is seen as something that, will requiring input from the Product Team, might be worth exploring.
  • A suggestion to lessen the reliance on high-res specular maps is for the Lab to provide a set of default grey textures at (say) 128×128 against which specular glossiness and environment could be set. A counter to this was that the blank white texture could be used and tinted to grey.
  • There was also general discussion on PBR and its possible introduction to SL in the future (it is *not* on the roadmap right now!) and its potential impact on existing content were it to be introduced.

2019 Content Creation User Group week #41 summary

Cherishville, August 2019 – blog post

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting, held on Thursday, October 10th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are available on the Content Creation User Group wiki page.

Graphics Team

There are two new Lindens now on the rendering team – Euclid Linden, who has been with the Lab for around a month at the time of writing, and Ptolemy Linden, who has been a Linden for the last couple of weeks, again at the time of writing. Both will be working on various rendering projects which will include the Love Me Render viewer updates and also projects like the Environment Enhancement Project (EEP) – which is considered a priority in order to move that project towards release.

Euclid Linden goes full-on shark-man, while Ptolemy goes a little more conservative with a starter avatar

Viewers

No further updates thus far in the week. The hope is that the Vinsanto Maintenance RC viewer (version 6.3.2.530962 at the time of writing) looks to be in “good shape” for promotion, but currently requires a little more time in its release cohort.

This leaves the official viewer pipelines at the time of the meeting as follows:

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

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

  • Work is progressing on building a predictive model based on the data LL has been gathering on mesh complexity, frame times, etc.
  • This model will be tested across a wider range of client hardware types and different ranges of settings.
  • The data thus far confirms that geometric complexity plays a large part in performance reduction, but also that there are a lot of other variables in play: rigged meshes are very different in behaviour impact to static meshes; some graphics properties can make a “big difference” in frame time, etc.
  • Details on the impact of textures has yet to be folded into the project.

Project Muscadine

Project Summary

Currently: offering the means to change an Animesh size parameters via LSL.

Current Status

Still largely on hold while ARCTan is being focused on.

Other Items in Brief

  • Mesh Uploader: a couple of points were brought up concerning the mesh uploader:
    • At the time mesh was introduced, materials were no supported; therefore, in the uploader there is code to discard tangent space (which can be used by normal maps). This means normals must be calculated in real time, causing both performance problems and inconsistencies between how normals appear in Second Life and how they appear in the 3D software used to create them. It’s been suggested this issue should be the subject of a Jira.
    • Allowing for the work on ARCTan, some see the uploader unfairly punishing on grounds of size and LI.
      • It what pointed out that a very large mesh that can be complex to render get hit with a high LI and high upload cost, but a very small object  – which may still have tens of thousands of triangles – is not penalised to the same degree, even though it might be as costly to render.
      • The alternative suggested was to have costs based not on LOD boundaries & changes rather than a simple size / LI basis. The idea here being that the cost is more reflective of what is seen and rendered by the viewer, which is seen as “levelling” the playing field (if a small object has a really high LOD tri count, then it would incur higher costs, in theory making creators more conservative in how they construct their models.
      • It was pointed out that in some respects complexity / LODs are already being gamed (e.g. by having one high LOD model then setting the medium and low LOD levels to use the same low poly version of the model for both and avoid costs for a proper mid-level LOD model), and such an approach as suggested might further encourage similar gaming.
      • Vir’s view is that the issue is not really that tied to the uploader per se, but is more in the realm of overall cost calculations (although LOD models obviously impact upload costs). As such, ARCTan is really the first step in trying to deal with these kinds of issues, and may help alleviate some of the perceived imbalance seen with upload costs.
  • Materials and Bakes on Mesh: a request was again put forward for LL to provide materials support for Bakes on Mesh. This is not an easy capability to supply, because:
    • System layers for clothing do not have a means to support any materials properties.
    • The Bake Service has no mechanism for identifying and handling materials properties to ensure they are correctly composited.
    • Thus, in order to support materials, both the system wearables and the Bake Service would require a large-scale overhaul which, given all that is going on right now (e.g. trying to transition services to being provisioned via AWS services), the Lab is unwilling to take on.
  • A request was made to allow 2K textures to be displayed by Second Life under “controlled conditions”, the idea being that a single 2K texture could eliminate the need for multiple smaller textures. The two main problems here are:
    • There is already a propensity for people to use high-res textures across all surfaces, whether required or not on the grounds “higher must be visually better”, so allowing even higher resolution textures to be displayed could exacerbate this.
    • Given there is no real gate keeping on how textures are used in-world once uploaded, how would any “controlled conditions” on the use of certain textures actually be implemented (both technically and from a user understanding perspective)?

2019 SL User Groups 39/2: Content Creation summary

Alternate Reality, August 2019 – blog post

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting, held on Thursday, September 26th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

This was a shorter than usual meeting.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

Work is continuing on getting the logging and analysis elements of the project up and running. Right now the (in-development) test viewer is described and pouring out a lot of “gibberish” on frame draw rates and all of the attributes in a scene, and the idea is to try to pull this together into a predictive model that is more accurate than the current rendering cost model.

Project Muscadine

Project Summary

Currently: offering the means to change an Animesh size parameters via LSL.

Status

  • Largely on hold while ARCTan is being focused on.
  • A bug whereby physics parameters weren’t being correctly applied has been resolved and a fix should be available in the next viewer update.
    • The default viewer-size avatar animations (fidgets, eye tracking, etc), were disabled for Animesh and have not been re-enabled, this update only applies to physics params.

Environment Enhancement Project

Project Summary

A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will now likely not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

  • A new graphics resource – Euclid Linden – joined Linden Lab last week. He is currently finding his way around the rendering system and will be working on EEP in the near future.
  • A further graphics expert is due to start with LL in the next month, and once up to speed, they will also be lending support to EEP.

General Notes

  • Script breakage: there have been a number of reports filed concerning script breakage recently (see: BUG-227669BUG-277667 and BUG-227659 for examples). The reports have been noted by the Lab but have yet to be triaged
  • The next CCUG meeting will be on Thursday, October 10th.

2019 SL User Groups 38/2: Content Creation summary

Grauland, July 2019 – blog post

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting, held on Thursday, September 19th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

  • An unexpected / unintended side-effect of Bakes On Mesh is the baseline avatar rendering cost has gone up by 1,000. This is due to the additional channels being added in support of BOM (so a basic, naked system avatar will have a complexity of 2,000 instead of 1,000). Vir is going to correct this.
  • Just as a reminder: there is no certainty as to how ARCTan will work – the Lab is focused purely on data gathering at this point, not on implementation. As such it is far too early to discuss policy, rules, implementation, etc.
  • One aspect that is being considered is to provide a set of in-world tools and / or example models to allow creators better understand what ARCTan might be doing and how it could affect their work. Again, this could only be done when LL is in a position to start moving forward with ARCTan.

Should Existing In-World Content Be Excluded?

One area of discussion on ARCTan has been the matter of existing in-world content: should it be subject to the new ARCTan calculations (whatever they might be) or excluded?

  • Arguments for excluding existing in-world content include:
    • Less risk of upset if changing values sees an increase in the land impact of items, prompting confusion among users (“why is my 16 LI bed now 26 LI?”).
    • Reduction in the possible large-scale return off objects by parcels / regions where ARCTan changes take them over their limit.
    • “Easier” to implement, as new costs only apply to “new” content.
    • Less work for content creators in updating their documentation (note cards, MP listings, vendor boards, etc.) to correctly reflect the “new” LI values for their goods that are changed as a result of ARCTan.
    • Reduces the risk of “permanent” content breakage in instances where the LI for objects rises to impact user’s ability to have them in-world, and the creator is no longer active to provide better optimised updates.
  • Arguments against excluding existing in-world content include:
    • Potentially limits the purpose of ARCTan in educating users about using decently optimised content.
    • Introduces questions on how new limited should be applied. On upload? On rezzing?
    • If on rezzing, user confusion may not be negated (“when I rezzed this bed last week it was only 16 LI; now when I rez it, it is 26 LI! Why?!)
    • ARCTan will not be an overnight implementation. LL plan to try to work with creators and users to provided information on changes, and work as far as possible to minimise the risk of content return.
  • The idea of excluding existing content has not been ruled out. But again, until the Lab have baselined their data, carried out experiments and tests in order to see the likely impact of various adjustments to the calculations / costs and investigated what can be done to mitigate some of them (e.g. increase the land capacity of regions), nothing can be decided one way or the other.

Core Content Projects Summary

  • Animesh Follow-On – Project Muscadine: effectively on hold while Vir focuses on ARCTan.
  • EEP: work continuing on rendering bug fixes, with additional resources being added to the project.

General Notes

  • Avatar Impostering
    • Concern has been raised over the complexity handling on Animesh with impostering. Currently, Animesh objects are handled the same as avatars. However, as they are a lot less complex, there is an argument to say Animesh should be handled differently to avatars when impostering.
    • This is being taken into consideration, with the possible introduction of a “max Animesh” setting for the purposes of impostering Animesh.
    • Whether or not this will affect the current baseline for impostering avatars is unclear; the work is still only at the point of discussion.
  • Mesh uploader:
    • There are reports of a rise in issues when uploading mesh models – failure to complete the upload, coupled with the production of hard-to-decipher “mav” errors.
      • So far as the Lab is aware, nothing has changed within the viewer or on the simulator side that might be causing the problems. Those encountering such problems are asked to file a Jira, preferably with  viewer log files.
      • There is a viewer with improvements to the mesh uploader in development. This may not resolve the issues, but it should offer improved feedback and messaging during the upload process.
      • It’s been suggested that the problem could be due to recent updates to Blender in saving .DAE files.
    • Many 3D tools are moving to use / support the glTF file format, which is currently subject to much discussion / criticism. Linden Lab has no plans to support the format at this point in time.
    • A few months ago, it was indicated that custom origin point (pivot point) for meshes would be implemented. This work is currently awaiting some back-end changes. As such, until these changes are made, the work is on hold.