2021 CCUG meeting week #50 summary

Elysium, October 2021 – blog post

The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, December 16th 2021 at 13:00 SLT. These meetings are chaired by Vir Linden, and meeting dates can be obtained from the SL Public Calendar.

Available Viewers

This list reflects those viewers available via Linden Lab.

  • Release viewer: version version 6.5.1.566335, formerly the Cache+ 360 Capture viewer, dated December 7, promoted December 15 – NEW – see: 360 Capture viewer now de facto SL release viewer.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • The Jenever Maintenance RC viewer, version 6.5.1.566306, issued on December 6.
    • The Koaliang Maintenance 2 RC viewer, version 6.5.1.565905, issued on December 6.
    • The Tracy Integration RC viewer version 6.4.23.563771 (dated Friday, November 5) issued Tuesday, November 9.
  • Project viewers:
    • Performance Improvements project viewer updated to version 6.5.1.566443, dated December 8.
    • Performance Floater project viewer, version 6.4.23.562625, issued September 2.
    • Mesh Optimizer project viewer, version 6.4.23.562614, issued September 1.
    • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
    • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

  • It is possible the two Maintenance RC viewers will be combined into a single release prior to their promotion in early 2021.
  • Work is continuing to work out the bug in the Performance Improvements project viewer in the hope it will be fit for promotion to RC status early in 2022.

Second Life Terrain Discussions

It has long been noted that the terrain in Second Life has never received a major overhaul, although the subject has been discussed from time to time. Currently, a terrain project still is not on the roadmap, but the floor was opened for suggestions as to what users might like to see if such a project were to be adopted by LL.

The questions was framed around “terrain” being the overall appearance of a region – land, water, the use of any region surround, support for flora, interactions with the wind, having much improved texture quality, etc., so as to offer a much improved graphical experience that does not put an undue load on the viewer when rendering or requires the simulator to send a mountain (no pun intended) of data to the viewer.  In other words, how to make SL landscapes / environments “prettier” and “more up-to-date” without undue impact on overall performance.

  • In terms of the existing system, suggestions put forward included:
    • The ability to have Linden water on a prim (rather than animated diffuse, normal and specular maps).
      • One problem here is the potential for serious performance hits (e.g. linden water on prim / mesh faces being used (or over-used!) for mirror effects) – particularly given actually occluding “non-visible” Linden water (e.g. the “water” beneath the terrain map) in order to help improve viewer performance is very much something being actively looked at (and is being implemented in the case of the Catznip TPV).
    • Support for using splat / weight maps.
    • Proper blending / integration between terrain and any region surround.
    • Ability to instance “proper” trees, grass a fauna (rather than the (circa 2002) default Linden trees, etc., included in the build tools.
    • Ability to blend / layer textures to allow things like a base of dirt, overlaid with grass, then the two blend to give the impression of wheel ruts or a dirty / rock path through the grass, etc.
  • It was also pointed out that there are multiple limitations to the current terrain system and tools (e.g. the inability to create tunnels or caves, limitations is blending terrain between parcels under separate ownership, the manner in which alterations to the height fields can cause a bad stretching of the surface textures, etc.), as such, many region designers already prefer working entirely in mesh, and so a better effort might be to provided improved support for this approach, including:
    • The ability to use large terrain meshes that are not prohibitively expensive  in terms of LI,.
    • Allowing proper texture blending on mesh terrain surfaces.
    • Support (again) for splat / weight maps. etc.
  • In terms of instancing flora, concern was raised how this might impact the landscaping market / economy (e.g. if LL provide a range of “nice trees”, will people still, buy their own? could the instancing system be made extensible, so that content from creators could be “plugged into” it?, etc.).
  • Overall, no conclusions were drawn, but a lot was offered up in terms of ideas, with the discussion also touched on issues of physics (notably the use of mesh terrain elements across region boundaries, the potential for increased physics collision calculations resulting on a performance hit; and also discussions of an expansion of the materials system allow the use of additional maps / making the materials system more a asset-based system (like EEP settings), consideration of updating SL to offer reasonable / real PBR support, etc.

4 thoughts on “2021 CCUG meeting week #50 summary

  1. After running Willowdale, a now 316 region estate, for just under 14 years and specializing in landscaping, I would honestly settle for a finer grid – 1024 instead of the current 256, and the ability to paint texture directly on the terrain with brushes that blur the overlaps. The ability to bake terrain per parcel instead of just the entire region would also be a great help. I prefer to plant my own vegetation.

    Like

    1. Baking options were discussed as a part of providing the additional materials channels to more robustly support baking for lighting, etc. Larger region sizes is something that has been discussed at length over the years (notably at Simulator User Group meetings), and the general feedback from LL is that the 256×256 region size is something that is fundamentally baked-into the much of the SL code base (notably the simulator), such that changing it presents a significant engineering challenge LL have previously been unwilling to tackle.

      Like

Comments are closed.