Tag: Content Creation 2018

2018 SL UG updates 43/2: CCUG summary

Posted on by Inara Pey
Alexa Linden’s Funky Love EEP sky

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.

Resources

Current Status

Land Impact: a simulator bug has been found that is being fixed. In short, if an Animesh object has a conventional prim as its root, the required 15 LI for the Animesh skeleton is not applied. This LI is an aggregate value for Animesh skeletons during testing Animesh performance for a defined set of test Animesh objects across a range of systems.

This has led to some alarmist blog posts about prim returns, following a (somewhat sensationalist) forum post on Animesh being delayed by 2 weeks (itself guesswork) on the matter. Given that Animesh hasn’t reached release status, and there are few (if any) commercially-available Animesh objects at present, it’s not unfair to say both the blog posts and the forum thread are something of an over-reaction.

Performance Impact: (see BUG-225584 and forum thread). This is related to the new dynamic bound box used with Animesh. Beq Janus from the Firestorm team has been involved in investigations as to the degree of potential impact, and has discovered a potential baseline performance impact of around 8-10% between an Animesh-capable and non-Animesh viewer, regardless of the presence of Animesh.

The latest update to the Animesh viewer (version 6.0.0.520636 at the time of writing), should mitigate a lot of the performance impact resulting from the dynamic bounding box.

Animesh vs. Avatars: while there will be a baseline impact for Animesh objects, this should be less than the baseline impact seen with avatars, which not only have a skeleton, they also have a shape and appearance elements associated with them. The the complexity of a mesh body to an avatar (with a baselines of around 400 faces, plus mesh clothing, attachments, etc., and avatars tend to be a lot more complex than most considered Animesh should be.

Animesh follow-up: there has been a lot of talk about a follow-up project for Animesh since the project started. These include adding a body shape (allowing Animesh humanoid objects to gain slider support), which is viewed by the Lab as being possibly the preferred follow-on project, although it is acknowledged given the wide variety of arbitrary mesh forms that could be converted to Animesh, slider use might be limited. However, it is unlikely any follow-on project will be an immediate follow-on to the current work, as there are several other projects currently in the pipeline awaiting attention.

Animesh attachments: another long-term request has been to attach objects to Animesh creations. A problem here is that attachments are managed by the simulator-side avatar agent – and Animesh objects do not have an avatar agent associated with them, so they don’t have the back-end support for tracking attachments. This is an issue that needs to be solved before attachments on Animesh can be handled – and even then, there is the question for potential performance impact. Various alternative ideas have been suggested to allow for attachment support n Animesh, but these may also have their own issues, and are unlikely to be adopted.

Animesh “assembling” issue?: we’re all familiar with the way mesh bodies “assemble” when logging-in / teleporting to an occupied region: the various mesh elements stack-up, usually at their default attach points, while some may appear offset or oversized, then the position, rigging, LOD, etc., data is received by the viewer and things “assemble” into an avatar. This behaviour can occur with multi-part Animesh objects as well, and there is a report that sometimes the Animesh “assembling” can leaves parts floating around for up to a minute before “snapping into place”.  Thus far, the problem has only manifested with one creator using the pre-release of the Firestorm Animesh viewer, so it’s not clear whether there is an underpinning issue with Animesh or not.

Environmental Enhancement Project (EEP)

Project Summary

A set of environmental enhancements allowing the environment (sky, sun, moon, clouds, water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. Uses a new set of inventory assets (Sky, Water, Day) that can be stored in inventory and traded through the Marketplace / exchanged with others, and which can additionally be used in experiences. A new set of render shaders to support atmospheric effects such as rainbows, crepuscular rays (“God rays”), better horizon haze and fogging (but will not include rain / snow). The ability to change the Sun and Moon and cloud textures with custom textures.

Resources

Current Status

As per my week #43 SUG update, a simulator update has been updated to fix the issue of racing skies when EEP-enabled regions are seen on non-EEP viewers. In addition, Rider is working on the first pass of the LSL support for EEP.

Bakes On Mesh

Work is continuing with fixing the Bake Service issues. however, as Anchor Linden, the lead for the project, is on vacation, this work will likely remain open until his return.

Other Items

  • Animations: there have been multiple requests for improvements to the animation system, including: allowing animation constraints to be set; extending the .ANIM format, animations by .DAE file and support for animation scaling. The Lab is aware of the requests being made, although not formal project has been defined at this point.
  • Morph Targets: there have been requests to allow morph targets within the avatar shape so that the shape sliders can be manipulated via LSL (so an avatar “gorging” itself at a scripted meal gets fatter, as a simple visual example). There are concerns that opening the body shape parameters to LSL manipulation could result in over-use and performance impact (e.g. rapid LSL adjustments to “animate” an avatar rather than using an actual animation), but some ability to allow morph targets is seen as potentially “interesting” – although this is not to say it will become a project.
  • Date of next meeting: due to the start-of-month internal meeting at LL, the next CCUG meeting will be on Thursday, November 8th, 2018.

2018 SL UG updates #42/2: CCUG summary

Posted on by Inara Pey

Storybook Forest; Inara Pey, September 2018, August 2018, on FlickrStorybook Forest – blog post

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, October 11th, 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.

Environmental 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.

Resources

Current Status

EEP is now running on around a dozen Linden-controlled regions on Agni (the main grid). Expect the server-side code to creep to other RCs soon.

Currently, running EEP on the simulator side can result in some strange skies when seen on non-EEP viewers (deep black skies, racing clouds, etc.). Rider and Graham Linden are working to improve this.

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.

Resources

Current Status

Work is contining with fixing the Bake Service issues. however, as Anchor Linden, the lead for the project, is on vacation, this work will likely remain open until his return.

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.

Resources

Viewer Status

The Animesh RC viewer updated on Thursday, October 18th to version 6.0.0.520636. The sees the viewer merged up to the release viewer and has some fixes for issues, notably:

  • Optimisations for dynamic bounding box computation on avatars and Animesh objects.
  • Animesh attachments should now match the impostor state of the attached avatar.
    • This may cause some discrepancies with the render max avatar setting (as a worn animesh should give a count of 2 (avatar and Animesh). However, this has yet to be tested
  • Animesh objects should no longer disappear when crossing region boundaries using the Mac viewer.

The hope is this will be the final RC update to the viewer, and that it will, in due course be promoted to release status.

Animesh vs. Mesh Alpha Flipping

One of the benefits of Animesh is that it should be more efficient, design-wise than the more usual alpha-flipping, potentially with a lower rendering cost. However, there are still questions around overall efficiency when it comes to general performance.

A problem here is trying to do like-for-like comparisons; something the Lab hasn’t attempted to test. Rather, their focus has been to test whether the overhead of Animesh itself is going to be detrimental to overall performance. As such, creators who have been using alpha-flipping with animating meshes will need to test the potential benefits of switching to Animesh for their existing products for themselves.

In Brief

  • Animesh tri count limit: the debate over whether the 100K tri count per Animesh is “enough” rumbles on (although it often feels as if only one creator perennially believes it should be higher for in-world objects). In short, the total is unlikely to be revised up or down, although project ARCTan might affect it in the future.
  • Mesh uploader: while no formal project has been announced, the Lab is hoping to take a look at the mesh uploader in the future with a view to improving it. So, if you’re a mesh creator and have some ideas on what might be done in this direction, now might be the time to raise your feature requests / bug reports.
  • Are upload fees an encouragement for efficiency? possibly, but questionable, in the Lab’s view.
    • Given that the upload cost is a one-time fee that could be made up after a few sales of the item / item the upload is used in (in the case of textures).
    • Plus, those wanting to use high-res textures directly may complain over an increase in upload fees for larger textures, but would probably keep right on uploading rather than questioning whether or not they need such high-res images on every surface they are texturing.

 

2018 SL UG updates #41/2: CCUG summary

Posted on by Inara Pey
A simple 5-minute (including uploading the textures) demo of EEP, replacing the Sun and Moon with Mars and Jupiter respectively, then adjusting their respective sizes &; putting them in the same quadrant of the sky

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, October 11th, 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.

Environmental 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.

Resources

Current Status

  • Testing still in progress on Aditi, with test parcels for users still available.
  • Test region: Aditi EEP Testing (secondlife://Aditi/secondlife/EEPTesting/128/128/23).
    • Parcels cost L$1, but as Aditi funds are provided by Linden Lab, you are not paying for anything with your own money.
    • You MUST be using the EEP test viewer why trying to purchase a parcel on the test region – if you are using any other viewer, your purchase will time out.
  • Feedback via Jira (bugs and requests) and / or through comments on the forum feedback thread.
  • An update to the project viewer is expected soon.
  • Graham Linden is continuing to work on the shader support.

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.

Resources

Current Status

The update to the Bake Service to support 1024×1024 textures has run into problems. Anchor Linden is working on fixes for the issues, and once these have been implemented then the viewer should receive and update as well.

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.

Resources

Current Status

  • The RC viewer updated on October 8th to version 6.0.0.520211. It had been hoped with would be the last RC version, but issues mean this will not be the case.
  • Performance issue:  BUG-225584 and forum thread. This is related to the new dynamic bound box used with Animesh. Vir is working on the issue, and Beq Janus from the Firestorm team has been involved in investigations as to the degree of potential impact. There have been one or two sensationalist blog headlines – best to read the forum thread and the bug report.
    • Part of the thread has spun away into handling attachments on Animesh. While this is not a part of the initial Animesh release, hopefully the discussions can be split off into their own thread.
  • Imposters issue: Animesh objects can imposter independently to avatars. This can result in an avatar rendering normally when seen by others, but any attached Animesh being impostered (or possibly vice-versa).
    • This is being fixed so that an Animesh attachment will now have the same imposter setting as its parent avatar. The update will be in the next RC update.
  • There is a Mac-specific graphics issue that can result in Animesh objects vanishing from the scene when crossing a region. This is also being worked on.

Animesh and the Marketplace

  • There has been some preliminary discussions in the Lab on how to make Animish distinguishable / locatable on the Marketplace (e.g. categories, etc.).
  • No decisions as yet, but the Lab is interested in feedback at CCUG meetings or through the Animesh feedback thread.
  • Problem here is the risk of confusion cross-over. Do trees animated via Animesh require their own sub-category under “Animesh”, should they have  an “Animesh” style sub-category under trees and shrubs (itself already a sub-category of Home and Garden >: Landscaping)?
    • There’s also the question of what to call an over-arching category: “Animesh” is a truncation of “Animated Mesh”, and has been used within the project, etc., but those unfamiliar with the project might be confused by it; so might “Animated Mesh” be preferable? A problem here is “Animated Mesh” itself is a little ambiguous in meaning.
  • Triangle counts have been suggested as an alternative, but this requires some form of automated count system for items uploaded to the MP, which in turn would require significant changes to the MP tools.
    • Even if a tri count could be auto-generated, would people take more notice of it or a given LI?

In Brief

  • A portion of the meeting was taken up with Blender / Maya specific conversations on bone placement for making taller avatars or for use in things like snakes and ropes.
  • There was some discussion on altering the axis rotation in the mesh uploader to match the likes of Maya and Substance Painter. As Vir noted in the meeting, there are an array of potential improvements that could be considered for the uploader – but as yet, a specific project hasn’t been defined to it – and any such project would likely be open for creator input.
  • Support for additional material maps: there has been various discussions (in the forums, etc), but SL supporting additional material maps – roughness, metalness, displacement, etc. Nothing official is on the table from the Lab,  but earlier in 2018, Kitty Barnett did some experimenting with displacement maps with the Catznip viewer – although this should not be taken to mean this is something that will be supported by Catznip or other viewers.
    • Vir hopes that Graham Linden will be able to give some thoughts on expanding material maps support in the future CCUG meeting.
Displacement maps, experimented with by Kitty Barnett earlier in 2018, might – if they could be implemented – add further depth to surfaces. For example: top left – a prim wall with a brick texture; top right: a prim wall with a texture and normal map applied, as we’re used to seeing in Second Life – some depth is added to the cement grouting between the bricks etc. Bottom centre: the same prim wall with the same texture added, but now using a displacement map: note the greater apparent depth between bricks and cement grouting, etc (highlighted).

 

 

2018 SL UG updates #39/3: CCUG summary

Posted on by Inara Pey
“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.

Resources

Current Status

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.

Continue reading “2018 SL UG updates #39/3: CCUG summary” →

2018 SL UG updates #38/3: CCUG – EEP! the sky!

Posted on by Inara Pey
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.

Resources

EEP Documentation

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

Continue reading “2018 SL UG updates #38/3: CCUG – EEP! the sky!” →

2018 SL UG updates #37/3: Content Creation User Group

Posted on by Inara Pey
“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.

Resources

Current Status

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.

Resources

Current Status

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.

Resources

Current Status

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.