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.


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


Current Status

  • The viewer is being merged up to the latest release viewer (version, 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.

3 thoughts on “2019 Content Creation User Group week #42 summary

  1. It took me a lot of digging to find any documentation, but the texture system downloads the full-size texture and locally generates the mip maps, using one based on the on-screen size of the texture. So features such as the Firestorm optional limit don’t save anything on download times. That would matter more to me in the days before I switched my connection from ADSL to FTTC, which is a detail to be wary of in any testing by Linden Lab. On reports I see, a lot of the USA has slow internet connections, unless they’re the Silicon Valley crowd.

    I’ve had a look at BUG-227767. I thought I understood how object size interacted with LOD switching distances, which feeds back into Display Weight/Complexity calculations, thus affecting Land Impact. Last I checked, texture costs were a simple fixed figure, based on the size, a trivial part of the total in many cases.

    Linden Lab need to sort out their documentation, though it still seems more coherent than that feature request.

    It would be nice to have a few small default textures to hook specularity to, but it’s not as though they’re hard to make. Remember that you need something in the normal map too. Both the Environment and Glossiness reflections can be modified across a surface by the alpha channels. The Normal map alpha channel modifies the Environment value. You don’t need the alpha channel in either case, but the texture has to be there.

    There are various ways of getting a cloud-like effect for textures, slight variations over the whole texture, and very few things are entirely uniform. Having a few per cent variation across the alpha channel, rather than a uniform specularity for the whole surface, might be quite effective. Remember to make the texture seamless


    1. ” but the texture system downloads the full-size texture and locally generates the mip maps, using one based on the on-screen size of the texture” – this is why it’s been suggested that uploads should generate a set of textures rather than an individual texture.


    2. The Goal for the feature request, is to separate size from LOD, I understand that Size is only apart of the equation because of the LOD factor behind it, I want to separate that. Currently Sculpted trees are prized over, vs Mesh trees primary because of this reason, sculpts usually end up being less land impact. In any case if you have any “constructive” feedback that I can place on the Jira to make it more coherent, I can update it to hopefully point them in the right direction.


Comments are closed.