The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, September 20th, 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.
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.
The complete EEP documentation is now available on the SL wiki. Published on the 19th September 2018, and still subject to update, it provides information on:
- Types of Settings – skies, water, day cycles.
- Creating and editing EEP settings objects.
- Applying environments and settings.
- Command commands for EEP objects.
- Setting fixed skies and water.
- Images of the new inventory options, the new UI options (My Environments, etc.).
The test viewer was made available on Thursday, September 20th, available for OS X, and Windows 32 / 64-bit. Testing is only available on Aditi, and the land there is limited; so for the time being the viewer download links are not generally available – but check the Alternate Viewers wiki page for its general availability in the near future.
- EEP testing is limited to one region on Aditi for the time being. Parcels are offered for sale at L$1 each (money on Aditi is automatically provided for users, so this is not a personal cost). Users are requested to only purchase one parcel apiece.
- Parcels can only be purchased via the EEP test viewer.
- There is not currently a forum thread, as this is only the initial test period for EEP, but a thread will be opened once the project moves to Agni, the main grid.
- It is hoped that EEP will move rapidly to project viewer status, and will be available on Agni in the near future – particularly now that the AIS service updates have completed.
- There is a single water track per parcel, so it is not possible to set different looks for water at different altitudes as you can for the sky (and anyway, most would be unseen at higher altitudes).
- Items still to be considered or to be completed:
- Offering users the ability to override the time of day/sun position within their own viewer irrespective of the permissions on the EEP settings pack.
- The shader atmospherics have still to be added.
- Scripting support has yet to be added – some scripts are available and awaiting inclusion, but it was always Rider’s plans to add scripting after the initial test / project viewers were available.
- The scripting work will include options for setting the environment on agents participating in an experience.
- To help with initial testing, Rider has produced a “sundial” that can be obtained in the Aditi test regions. This contains all the available functions and is designed to be used for determining the positions of the Sun and the Moon.
- The Sun and Moon move entirely independently to one another, allowing both to be in the sky at the same time, and their size can be enlarged or reduced, depending on requirements / texture being used to replace them (so you could have a massive planet hanging in the sky, as if close by, or a little moon that appears much further away).
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
Two new issues have cropped up, the results of changes being made to Level Of Detail (LOD) handling and distance calculations.
- The first is that some non-rigged attachments show as lower LODs than they should.
- The second was that HUDs were also showing at lower LODs than they should, despite being attached to screen space.
Vir believes he has fixes for both of these issues (the latter being that HUDs are now always set to display LOD 3), which will be in the next Animesh viewer update. It is still not clear whether the next viewer update will also promote it to release status, or whether it well be another RC update.
There are a number of cosmetic / corner-case issues remaining which may not be fixed prior to the viewer going to release status, Vir’s view being it’s better to get the project to release status and they do small nips and tucks to the viewer as part of the normal viewer update cycle.
The 90-degree rotation issue with the Animesh test content that resulted from viewer-side updates (and which left items of this content crabbing sideways when it should have been walking forward), is in the process of being fixed. Update test content should be available soon.
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.
Bakes on Mesh has been waiting for three updates that need to be carried out in order:
- Inventory updates for the new wearable asset types used with Bakes on Mesh. These (and the asset type updates required for EEP) were rolled into a large AIS – Advanced Inventory Service – that has apparently now been deployed.
- Bake Service Update to support 1024×1024 textures.
- A simulator update.
The Bake Service updates and the simulator updates currently do not have an ETA.
Height Information In Appearance Editor
Penny Patton (whose guide to avatar proportions I’ve long used, raised the long-standing issue of avatar height, as reported by the Appearance editor, being incorrect when compared to physically measuring the height of an avatar in-world – see VWR-19767 (which was closed with no action). This can understandably cause confusion when trying to design a correctly proportioned avatar shape of a certain height – as Penny’s 2011 blog post points out, it can mean a lot of buggering about with prims as “tape measures” to get things right.
Part of the issue is the manner in which avatar height is calculated – using bone positions, rather than a straightforward “floor to top of head” required to accurate scaling. As Penny notes in a blog post, this is both a visual issue when trying to model an avatar shape – but it can also impact content creation , as many people base the scale of their designs – building, animations, etc., on a perceived avatar height.
As a result of discussions at the CCUG, Penny has submitted a feature request – BUG-225513 – suggesting the providing of in in-world visual height indicator to help people model their avatars. If accepted, it’s not clear where it would fit in the list of the Lab’s priorities, but if you have an interest in accurate avatar scaling, this might be a Jira to Watch, and if you have specific thoughts about, offer your own feedback (drop a line to letmein-at-lindenlab.com if you do not have comments rights on the Jira).
The mesh upload floater is both difficult to comprehend and has a number of issues within it: its fixed size, lack of clarity in the preview window, etc. Suggestions for improvement have been put forward, and Vir has indicated that – depending on work priorities – there is a hope that there will be time post Animesh for work to be put into improving the uploader. If there are ideas for improving the uploader that are not already subject to a Jira, now would perhaps be the time to submit them as a feature request. Doing so could help the Lab determine the level of work involved and which options they might want to implement.