The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, September 13th, 2018 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.
The choppiness in some of the audio segments where Vir’s voice drops out is due to issues with SL Voice. Topics blow are not necessarily presented in the order in which they were discussed, I’ve attempted to group items by subject matter.
Environment Enhancement Project (EEP)
A set of environmental enhancements, including:
- The ability for region / parcel owners to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
- New environment asset types (Sky, Water, Days that can be stored in inventory and traded through the Marketplace / exchanged with others.
- Day assets can include four Sky “tracks” defined by height: ground level (which includes altitudes up to 1,000m) and (optionally) 1,000m and above; 2,000m and above and 3,000m and above, plus a Water “track”.
- Experience-based environment functions
- An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.
- There are no EEP parameters for manipulating the SL wind.
- EPP will also include some rendering enhancements and new shaders as well (being developed by Graham Linden), which will allow for effects such as crepuscular rays (“God rays”)
- These will be an atmospheric effect, not any kind of object or asset or XML handler.
- The new LSL functions for finding the time of day according to the position of the windlight Sun or Moon have been completed,and are more accurate than the current options.
- EEP will not include things like rain or snow.
- It will still be possible to set windlight local to your own viewer.
EEP is now “so close”. A test viewer is ready to go – note test, not project -, the major blockers have all be cleared, and land is being set-up on Aditi for people to be able to test the EEP capabilities there. An outstanding issue is documentation on how to create EEP assets, etc., but this could be available in week #38 (commencing Monday, September 17th).
As part of the update, Graham Linden has adjusted the night-time sky so that those running their viewer with ALM enabled will see stars at night, rather than dots in the sky – and they can twinkle!
The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.
- Animesh User Guide
- Animesh test content
- Animesh LSL methods:
- Animesh – Updated Limits and Cost Formulas
- Animesh feedback thread
- JIRA filter for Animesh
Work is continuing trying to clear the last few significant bugs the Lab would preferably like resolved or at least understand in terms of cause, before the project goes to release status. Vir has also been working on the constraints for scale and position with Animesh objects.
Bakes On Mesh
Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves viewer and server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.
This work does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables.
No real change. Still awaiting the AIS updates (which also adds support for EEP assets as well). This needs to be deployed before the associated Bake Service updates and simulator update in support of Bakes on Mesh can be deployed to Agni (the main grid). In the meantime, Bakes on Mesh can be tested on Aditi on the Bakes on Mesh test region.
Vir also reaffirmed that there are no plans to implement materials support with Bakes on Mesh at present, for the reasons noted above in the project summary. However, this might be revisited in the future.
As an aside: the main aspect of the AIS update is related to the ongoing work to move Second Life services to a cloud infrastructure.
Texture Use Discussion
Part of the meeting was given over to textures and their misuse within Second Life, with suggestions being offered on how to improve things.
Texture Upload Costs Based On Resolution / Size
One suggestion was to charge texture uploads based on resolution / size (so the higher the resolution, the greater the upload cost). This is not something the Lab is considering, and it seen as being of limited benefit unless set ridiculously high, simply because the upload cost is a one-time fee and does not discourage repeated (and over) use of a texture once uploaded.
Ability to Set Texture Resolution
An alternative suggestion would be to use the viewer’s discard levels (/mipmapping – see here for more) as a means for users to control what texture resolutions are used when displaying an object (or multiple versions of an object). So, for example, if an object uses 1024×1024 texture, but is only used as a “background prop” – objects in a vending machine or display case, for example), a user can use a viewer UI option to restrict the texture resolution of that object to a specific discard level, regardless of whether or not the objects in zoomed in on.
Some issues with this idea are that a) it would require additional data to be manipulated, together with an additional UI element; b) it would require a re-working of some of the viewer logic. Currently for discards to be used, the highest resolution of a texture must be loaded by the viewer; for this approach to be effective, the logic would need to be changed so that only the desired discard (with its lower video memory footprint) is loaded, avoiding the download of the highest resolution version completely. This also potentially shifts the onus from creator to consumer for using textures responsibly, which isn’t necessarily ideal.
- Transparency shadow casting from rigged items: there has been a long-standing issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by them to render incorrectly (shadow rendering conforms only to the geometry silhouette). Graham has now fixed it, and the fix should be appearing in the next round of viewer rendering fixes due out after the current Love Me Render viewer (version 18.104.22.1688751, dated August 20th, at the time of writing). This will work with static mesh and Animesh, once it has reached release status.
- Blending / mixing textures on a mesh face: the ability to blend / mix textures on a mesh face (in a “similar” manner to how they can be mixed on terrain) has been requested a number of times. Graham linden indicated this is unlikely to be implemented as it would, “require many new shaders and break batches more often (i.e. be less performant).”
- Mesh uploader: there is a significant list of issues and feedback on the mesh uploader and what could be done to improve it and help people better understand how to optimise content on upload, or make the uploader better behaved. Vir hopes that these will be looked at in the not-too-distant future, depending on what are seen as the next immediate projects to follow Animesh, EEP, etc.
- Projectors-as-facelights and hair styles: part of the meeting include a discussion on people now unfortunately using projectors as facelights to offer form of cubemapping on their avatars, and the new trend in having hair that contains multiple styles (e.g. ponytail over left shoulder or over the right shoulder or down the back). Both impose additional performance hits (the hair particularly so), while the projectors-as-facelights can also impact how a scene is rendered (if an avatar is close to you wearing multiple projectors, you may not see the results of some / all of any projectors used in the same space you are both occupying).
- Mesh loading by Script / UUID: the ability to dynamically load meshes using their UUIDs was part of early mesh testing, but was removed for a number of reasons – such has performance (for example, and while separate, people were using the ability to load via UUIDs for animation flipping, which caused a big performance hit). Dynamically changing worn mesh items via script is viewer rendering intensive, given the potential frequency with which it could be done – which it turn becomes a potential griefing vector. There is also an issue of potential content theft in making an asset’s original UUID obtainable. As such this is not something that is liable to be re-implemented.
- Apple OpenGL deprecation: the Lab is continuing to give thought as to what to do in light of this, but is not in a position to make a formal announcement as yet. Given that there are a fair number of Mac users at the Lab (including Oz Linden!), it is unlikely that the Mac version of the viewer will be left to “go away”; in fact Graham Linden anticipates it becoming something of a focus for him in the near future.