Storybook 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)
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.
- Project definition document.
- Project summary (this blog).
- Full EEP Documentation.
- Project Viewer – via Alternate viewers wiki page.
- EEP Feedback forum thread.
- EEP sneak peeks forum thread.
- EEP Jira filter.
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
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.
Work is continue 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.
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
The Animesh RC viewer updated on Thursday, October 18th to version 184.108.40.2060636. 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.
- 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.