“All these worlds are yours….” An alien sky by Cube Republic, using the EEP test viewer
The majority of the following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, September 27th, 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.
SL Viewer Update
The Rakomelo Maintenance RC, version 5.1.9.519298, dated September 5th, was promoted to de facto release status on Wednesday, September 26th. This means all other viewers currently in the pipelines will be merged with this code and updated in the coming days.
Environment Enhancement Project (EEP)
Project Summary
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, Day 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.
There will be a formal LL blog post on EEP testing at the start of week #40, which will include links to the current versions of the test viewer and also the SLurl for Aditi testing. I’ll be updating this summary with the details once officially made public. These will include the latest iteration of the viewer
Those who have been fortunate enough to attend the CCUG meetings have been able to get some advanced testing done, and there have been a number of additional bug reports and feature requests raised – use the EEP Jira filter to review all raised issues / ideas.
The latest version of the test viewer (made available at the meeting) will result in visible changes to cloud speeds. This will cause clouds in settings created using the initial version of the test viewer to travel much faster and to the north-east.
Another simple EEP demo showing how different textures used on the Sun or Moon within individual sky settings can be blended together when creating a day cycle & some of the motion effects – in this case the Sun (as Mars and Jupiter zig-zagging gently up and down). Oblateness is due to manual recording ratio, and is not representative of the texture shapes when seen in-world.
Cliff Notes on EEP
Graham Linden’s shader work has yet to be added to the viewer (so no crepuscular (God) rays, etc., as yet).
Firestorm uses a broader range of setting for atmospheric / water effects (haze, density, etc.) than the official viewer. This has led to windlights imported into EEP settings not displaying correctly (see BUG-225537) Rider had increased the settings range in EEP to match Firestorm.
Rider and Graham are discussing how procedural texturing might work in EEP(!)
EEP does not support the ability for anyone to create a new EEP settings object simply by saving the one they are viewing ( as can currently be done with legacy windlight settings). However, existing windlight settings stored locally in the viewer can be imported to EEP and converted.
EEP will break RLV controls on windlight.
The EEP test viewer can be used as an ordinary viewer on Agni (the main grid), but EEP settings cannot as yet be applied, and it may lead to a duplication of the EEP Settings folder when switching back to the test region on Aditi.
Cloud Perturbation
Rider hopes to be able to add a means to provide a degree of perturbation when non-seamless cloud textures are used, so that they don’t appear so tiled when viewed in-world.
Whirly Fizzle casts her magic, blotting the Sun with EEP. Credit: Whirly Fizzle
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)
Project Summary
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.).
Test Viewer
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.
And for those who have been eagerly awaiting it – the EEP viewer has options for setting the length of day at either region and / or parcel level, and the number of hours offset from GMT the cycle should be. Day lengths can be the default 4 hours, through to a maximum of 168 hours, equally to a week-long cycle
General Points
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).
A simple 5-minute demo (including uploading the textures) creating a sky object, using it to replace the Sun and Moon with Mars and Jupiter respectively, then adjusting their respective sizes and putting them in the same quadrant of the sky before applying the setting to a parcel of land. Note the windlight clouds drifting in front of Mars. Not visible in this image is the fact that with ALM in the viewer enabled, the stars twinkle as though with atmospheric distortion. Click for full size, if required
“That’s no moon…” – Rider Linden teases with possibilities whilst talking Environmental Enhancement Project (EEP)
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)
Project Summary
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!
Twinkle, twinkle little stars – EEP allows stars to twinkle in SL (you may have to click the image to open it and zoom into the GIF to see the effect better). Credit: Alexa Linden
Animesh
Project Summary
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.
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
Project Summary
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.
In Brief
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 5.1.8.518751, 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.
EEP! The Sky! Alexa Linden toys with the upcoming Environment Enhancement Project (EEP) capabilities to produce some eye-twisting skies. Courtesy Alexa Linden
The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, August 30th, 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.
Animesh
Project Summary
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.
In support of the server end of Animesh being grid-wide, and the viewer being in RC status, Vir Linden posted an update to the Animesh discussion thread in the forums. The post underlines the point that now is the best time for some final testing of the initial Animesh capability before it rolls forward to a formal release in the not-too-distant future, when it will be harder to make changes out of concern for breaking existing Animesh content.
In particular, the post makes mention of the fact that moving forward, Animesh will see a behavioural change:
We will be enforcing a size limit on Animesh objects. This will give more consistent behaviour with other types of prims, for which size limits are enforced. The exact details of how this will work is still to be determined, but you should assume that Animesh objects cannot become arbitrarily large.
The reasons for this is that there is no upper limit imposed on rigged mesh objects (whereas all other types of in-world objects have a limit), and there is a concern that if Animesh is not capped, then people could make very large objects that generate rendering issues for those viewing it (see BUG-225331 for more), or as a means simply to grief.
What the limit is and how it is to be enforced is still TBA, but at the CCUG meeting, Vir indicated that the real-time bounding box calculations may be leveraged.
One bug the Lab are trying to poke at is “stuttering” with some Animesh motion. The underlying cause of this has yet to be identified.
Animesh and Resetting the Skeleton
Vir asked the question on when should a skeletal reset occur on an Animesh objects. For example: an Animesh dog has accessories that can be attached / detached by adding / removing from the linkset via script. Should the skeleton for the dog be automatically reset from the removal of an attachment, or should it be a manual reset by the user? Most attachments may not require a reset, unless they were altering the dog’s shape; however, forcing a reset could also mean any animations running on the Animesh would also have to be reset, making things a little complicated. The consensus opinion swayed towards leave things as is, rather than force a reset, and allow creators determine how to handle things.
Bakes On Mesh
Project Summary
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.
Bakes on Mesh is still awaiting the main grid deployment of the AIS updates needed to support the new Bakes on Mesh (and EEP) asset types. As noted in my previous CCUG summary, Bakes on Mesh also requires updates to a number of back-end services (e.g. the Bake Service), and to the simulator itself, all of which have yet to be implemented. The viewer, meanwhile is more-or-less ready, but may see a further project status update.
Environment Enhancement Project (EEP)
Project Summary
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 described as being “very, very close” in terms of server-side support and a project viewer.
An issue with testing has been that a long-standing bug on Aditi (the beta grid) has meant that the Lab has been unable to set parcels them for sale, allowing users to purchase them (funds on Aditi are provided by the Lab – and are non-transferable to Agni! – so purchasing land there is effectively a zero-cost transaction to the user) and then carry out their own EEP testing. This issue has now been resolved by Rider and Ekim Linden, so parcels are now available on the beta grid for those wishing to test EEP once the EEP project viewer is available (as the necessary viewer-side update will initially be in that viewer), and assuming the server-side support hasn’t already been deployed to Agni to allow testing on the main grid.
Another EEP teaser from Alexa Linden
Other Items
Animations: Obtain by Name or UUID? A Case of Permissions
The middle of the meeting saw a discussion on whether calling animations by name or UUID is “more secure”. In short, calling by name requires the animation to be in an individual’s inventory, and thus seen by the Lab as more secure in preventing theft. Calling by UUID opens the potential to animations being physically obtained from the CDN should the UUID be unfairly obtained.
The question was prompted out of concern that is it possible to remove animations (and other items) from No Modify objects ad use them elsewhere – which (it seemed) one or two creators want to prevent. This comes down to more to how the permissions system works, more than anything else (No Modify means an object cannot be physically altered or added to; it does not mean its existing contents cannot be removed). Preventing the removal of an objects contents (whether animations or anything else) would require a significant overhaul of the permissions system.
Link / Unlink Permissions for Experiences
A request was made no adding the ability for experiences to be able to request permission to link / unlink objects without the need for individual requests to be made for each link / unlink operation – something which could be useful with Animesh. This has been discussed in the past, but is seen as being a larger project than something specific for Animesh, although it is seen as a useful capability (along with the means to offer mod keys for No Modify objects). Right now it is unclear what form such a project to provide capabilities like this would be, or where it would fit in the overall SL enhancement roadmap.
In Brief
Release Candidates and Project Viewers: generally speaking, if you are using either a Second Life release candidate viewer or a project viewer, you will not be automatically updated to an other viewer version, but you will be updated to the next available version of the RC or project viewer you are using, by the viewer update process. The exceptions to this are with RC viewers – such as the promotion of the viewer to release status (you will receive updates to later release promotions unless you opt to use another RC), or the RC is withdrawn (you will generally be updated to the current release viewer). Details on the release candidate viewer process can be found in my 2013 post: New viewer release process implemented.
Experience Keys: Oz confirmed that there is a plan to allow Premium users to have more than one experience key (allowing them to make multiple individual experiences, rather than having to use the same one for different purposes). The time frame for when this will be implemented is still TBD, as it requires a certain amount of back-end work.
Date of next meeting: Thursday, September 13th, 2018.
“That’s no moon…” – Rider Linden teases with possibilities whilst talking Environmental Enhancement Project (EEP). Credit: Rider Linden
The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, August 23rd, 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.
Animesh
Project Summary
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.
As noted in my Simulator User Group updates and Viewer Release summaries, the Animesh viewer was promoted to release candidate status in week #33 with the release of version 6.0.0.518579 on August 13th, 2018. The three key points of this are that:
Animesh is one step away from being the de facto viewer release – although this is dependent on a range of factors, including the other RC viewer in the pipeline, the viewer’s performance whilst at RC, etc.
Animesh capabilities will now naturally be available more widely among users of the official viewer.
Third-party viewers are now officially allowed to incorporate Animesh in their offerings.
Server-Side
Animesh has been on general release server-side across the grid for the last couple of weeks, and thus far, no problems have surfaced with in. However, this could be due to a relatively low usage of the capability up until now, given it has only be available within project viewers.
Sample Content Rotation
As noted in past CCUG summaries and updates in these pages, a workaround for rotation issue with uploaded models now means that some of the Animesh sample content provided by the Lab – such as the raptors used in the GIF file I often use to banner these reports – now crab sideways rather than walking forward when seen in the Animesh viewer. Following a suggestion put forward at the meeting, Vir is going to see if the affected content can be updated so that it moves correctly and can be provided as samples for people wanting to play with Animesh without potentially confusing them.
It’s also been pointed out that the scripts used within the sample content are very specific to that content, and so could lead to problems if people try to pull the scripts and use them as templates. However, Vir is uncertain as to how generic the scripts can be made in order for them to work as templates.
Bugs
There are still a number of bugs the Lab is working on in relation to Animesh. These should be listed in the JIRA filter (link above), and are related to some Animesh editing issues, animation stop / restart issues, and some lagging, possibly due to the underlying skeleton lagging behind the animation playback (so the Animesh isn’t properly oriented as an animation starts to play, for example). Not all of these issues may be fixed before Animesh reaches de facto release status, but Vir is continuing to try to work through them.
Environment Enhancement Project (EEP)
Project Summary
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.
Alex Linden from the product team has been working on internal testing with Rider, and is now in the process of moving the pieces into place to have EEP deployed the Aditi (the beta grid). Rider believes that a project viewer should be surfacing “very, very soon” as a result. The plans for the project viewer are:
Get the assets support in to the first release.
Hopefully include crepuscular rays (“Godrays”) and work on shaders for distance fogging and atmospheric density in the first release of the project viewer as well. However, as these are in fact another shader, they may not make it into the initial cure of the project viewer, depending on how things go.
Add the scripted ability to manipulate EEP assets at a later date, but before the viewer progress to RC status.
As well as discussing project progress, Alexa and Rider also indicated some of the things they’ve been playing around with while testing EEP.
Cthulhu the sun, Cthulhu the sun / And I say it’s all right – as the Beatles never sang: Rider Linden has fun with EEP. Credit: Rider Linden
Bakes On Mesh
Project Summary
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 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.
Still awaiting the AIS updates (see below). Once these are in place there are a couple of other back-end pieces that require putting into place.
AIS Update
Both EEP and Bakes on Mesh are awaiting a AIS (Advanced Inventory System) update that will provide the necessary back-end support for both projects on Agni (and Main grid), as each is adding new inventory asset types to Second Life. Currently, it is believed that the work on support for Bakes on Mesh is a little further along to allow it to take advantage of the AIS update, and the latter may start being deployed in week #35 (commencing Monday, August 27th, 2018).
In Brief
In-world meshes bigger than 64m on an axis: there are no current plans to allow the upload of in-world meshes that exceed the 64m limit. The main reasons for this are:
Vertex resolution: the larger the object, the greater the distance each vertex integer has to span, leading to inaccuracies in positioning (think prim drift for mesh), together with resolution degradation.
More particularly, the griefing potential and possible performance issues (e.g. rendering load on the viewer and possible implications for the physics engine).
Sim surrounds: partially in line with the above (and also ARCTan, below, given the use of sculpts), the Lab is interested in learning more above how people might like sim surrounds to be addressed. Some ideas offered include: making surrounds a specific form of large mesh with physics automatically disabled at upload (possibly used with a special field within the Estate / Region floater they can be “dropped into” to be applied; continuing with sculpts (with their 1 LI advantage over other potential land impact loads & their potential to have a relatively low number of vertices and thus form relatively economical content).
Project ARCTan: the project to recalculate object and avatar complexity will be progressing, however, it involves input from Graham Linden, who is currently focused on the shader / rendering work for EEP. However, data collection is continuing.
People are starting to question what this will mean for sculpt(ie)s in SL – the majority of which tend to be horribly inefficient in terms of rendering. The short answer to this at the moment is the overall impact hasn’t been determined.
Real-Time bounding box tracking: the question was asked whether the new bounding box calculations introduced as a part of Animesh will include “unused” joints (e.g. if the hind legs in the skeleton are not rigged to, are they included in the bounding box calculations?). short answer: no; with the exception of the original (pre-Bento) base skeleton joints (as used by the system avatar).
The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, August 9th, 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.
Animesh
Project Summary
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.
As of the SLS (Main channel) grid deployment on Tuesday, August 5th, the server-side support for Animesh is now grid-wide.
Animesh Viewer
Vir has completed work on the next update to the viewer, which includes a number of fixes and tweaks. This is currently with the Lab’s QA team. If all goes according to plan, this could see the light of day as a Release Candidate viewer. In particular, this update should include a fix for the bounding box / LOD issues previously reported in these summaries.
General Discussion Points
The LI accounting aspect of Animesh is considered “complete” for the initial release, and no further changes beyond the accounting values Vir has published via the Animesh forum thread are expected.
However, there may still be future revisions to the overall Animesh costs (complexity) as a result of the Project ARCTan work to overhaul all of the complexity calculations in order to make them more reflective of the actual costs involved in rendering, etc., different objects. This work has apparently been on hold recently.
Land Impact: streaming costs / LODs: there was further discussion on the 50% bounding on LODs.
Concerns have been raised at the disparity between the 50% cut-off between the high and medium models compared to the GLOD (Global LOD) cut-off of around 30% (so 70% discarded). Other concerns relate to the 50% between the medium and low models disincentivising creators from trying with a low model. An overall concern is that people will continue to look purely at land impact, rather than considering complexity and optimisation as matters of improved performance.
Vir admits the approach taken with Animesh is something of a trade-off between trying to encourage considered use of LODs and implementing a system that “scares people off” because of its demands. As such, it is something that may be revisited as a part of ARCTan, after more data has been gathered as a result of Animesh being released in the meantime.
A major difference with the “new” system is that it no longer considers scale. This means that creators who animate their creatures using a combination of multiple models and using alpha masks to hide the “unseen” versions and who reduce the “unseen” models to avoid them raising a creature’s LI, will no longer be able to do so.
Per-bone scale animations: having the ability to use per-bone scale animation, which could be particularly useful for non-human bodies (and now Animesh) has been a request since Bento.
Currently, the SL animation format doesn’t allow scales to be specified, so an overhaul of the animation system would be required to make this possible.
A further problem is scale animation can conflict with any use of the shape sliders, when used to modify an avatar shape (one of the items under consideration for a future update to Animesh is support for a body shape and the use of sliders).
The benefits with scale support include:
The ability to create a single creature body and use it in different species of that creature without the need to develop new animations and new rigged attachments (so a “dog” body could be used for a Labrador or a Chihuahua or Dashhound).
The ability to have “young” creations (babies, puppies kittens, hatchlings….) “grow” over time.
The ability for creators to develop a broader range of different NPCs and different creature types without having to rely on the avatar shape / slider system, which is inherently biased towards human forms.
An alternative to animation scaling (and subject of a feature request) that was initially made during Bento, was to have an overall body size slider that could proportionally adjust the entire size of the shape associated with an avatar (and Animesh, if shape and slider support is added to Animesh in the future).
One issue with implementing this at present is that the message format use to communicate slider parameters may not support the level of messaging required to communicate an overall rescaling that affects every joint and bone position at once (which would require updates to the Appearance and Bake services as well, so this would require an overhaul.
A further issue is that of locomotion: the same overall locomotion graph is used regardless of size, so in a single stride, a very tiny avatar made using a “size slider” could appear to move the same distance as a “normal” sized avatar, which can result in it appearing to move really quickly;similarly a really tall avatar created using a “size slider” could appear to hardly move at all each time it takes a step. So, the locomotion graph would need to be overhauled.
Use of per-bone animation scaling hasn’t been ruled-out, with Vir pointing out that even adding body shape and slider support to Animesh is complex, requiring further updates to the Appearance and Bake services in order to work. So it might be something to consider alongside of considering shape / slider support once the initial Animesh project is released.
Bakes On Mesh
Project Summary
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 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.
There do not appear to be any blockers within the project preventing it from moving forward. However, as indicated at the July 27th TPV developer meeting, there are some changes being made to the AIS system, and the updates to inventory required in support of Bakes on Mesh (which also requires updates to the Appearance and Bake services as), are currently awaiting that work to be completed.
Environment Enhancement Project
Project Summary
A set of environmental enhancements, including:
The ability 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 remains on internal testing at the Lab, although as I noted in my previous CCUG summary, Rider has been teasing us with images in the forums. According to Dan Linden. the viewer UI is “pretty much” complete, and work is focused on some of the back-end messaging, which appears to be holding things up. There may be a further update on status at the next TPV Developer meeting on Friday, August 10th.
Other Items
Transparency shadow casting from rigged items: there is an 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). This is still within Graham Linden’s pile of work.
Next Meeting: the next CCUG meeting for August 2018 will take place on Thursday, August 23rd.
Inara Pey: Living in a Modemworld 