North Brother Island, June 2019 – blog post
The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, August 15th 2019 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.
Items Coming out of the SL Summit
- LL might potentially be looking at a refresh of SL terrain texturing in the near future.
- Pathfinding is recognised as a pain-point, but no resources are available within the Lab to tackle improvements / enhancements in the immediate future.
An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).
- The project has been on hold for some time, but due to be rebooted during the current quarter.
- Emphasis will initially be on data gathering, as previously.
- No decision has yet been made on whether or not the first pass of work (once the data has been gathered) will include avatar accountability (including a further pass with Animesh), or initially only focus on in-world objects.
- The overall aim is that of encouragement – getting users to think and want to be on-board with the changes, as they can see the benefit.
- This work will not reduce the maximum texture size (1024×1024 – and remembering that for Bakes on Mesh avatar texture sizes have actually been increased from a 512x512cap to 1024×1024). However, ARCTan might penalise for “improper” use of textures (e.g. multiple uses of unique 1024×1024 textures across object faces, no matter how small the faces might be).
- There are a lot of ideas around ARCTan (e.g. finding a means to not encourage lowest LODs of near-zero triangles, not penalising people if they include valid LODs, etc). However, threading the need to find the right balance on how things should be handled is acknowledged as being difficult, and as such, do not expect ARCTan to start changing anything soon.
Environment Enhancement Project
A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.
Due to performance issues, the initial implementation of EEP will now likely not include certain atmospherics such as crepuscular rays (“God rays”).
- Project definition document.
- Project summary (this blog).
- Full EEP Documentation.
- The viewer should be updated shortly to bring it to parity with the most recent viewer release (version 18.104.22.1689638, formerly the Love Me Render RC).
- There are still issues on the rendering side affecting people on various graphics systems that need to be resolved, together with some remaining performance issues.
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 Bake Service to support 1024×1024 textures, but 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. Adding materials support may be considered in the future.
- Bakes on Mesh knowledge base article.
- Bakes on Mesh forum thread.
- Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).
- Still a number of bugs to be resolved, and Vir is now working on these as well as the Animesh follow-on (below). These include, but are not limited to:
- Shadows are failing to render correctly.
- Issues with some alpha settings.
- Otherwise, most of the functionality is now believed to be in place.
Animesh Follow-On – Project Muscadine
- DRTSIM-421 on Aditi (region Bakes on Mesh) now has the server-side code to support the new visual parameters LSL code.
- Project viewer supporting the new LSL code should be out for use on Aditi in the next week.
- This will provide the means to test the new LSL code functionality, but as with all project viewers, may not work 100% in all other areas.
- May get enhanced with additional Animesh-related capabilities, although this is dependent on commitments with other projects, notably Bakes on Mesh and Project ARCTan.
Possible SL Wiki Deprecation?
- For the last few years, the Lab has been moving information away from the SL wiki and into knowledge base articles.
- During a recent Web User Group meeting, it was indicated that this trend will continue, and that the use of the SL wiki may be deprecated over time.
- One of the reasons for this is the wiki software has some issues, and there are problems in opening the wiki for general management by users.
- These changes will not result in the wiki immediately vanishing.
- It’s not clear as to the best mechanism for getting outdated / incorrect knowledge base articles corrected – potentially the best way at the moment is to raise a bug report.
The wiki situation prompted a broader discussion on documentation.
- LL has been considering how to better provide documentation and demonstration videos for upcoming features and new capabilities.
- It has also been suggested a Content Creation blog where notes on projects, best practices relating to them and for things like mesh design – LODs (including how to make efficient low LOD models rather than just tossing a low number of tri into the mix) – uploads, etc., and other content creation information could be posted.
- It is acknowledged that there is a lot of expertise within the Lab and within the community for content creation, and none of it really resides within a single individual – therefore determining what should be documented, how it should be documented, etc., is not an easy matter.
- A lot of the existing best practises for content and build has come from users / creators.
- Given the status of the wiki, adding to this is currently difficult.
- While creators have produced their own documentation, etc., it does come at a cost, and tends to focus n their own specifics. Leveraging this into a more general set of best practices and documentation library would take a lot of further time and effort.
- As such, some sort of collaborative effort between creators and the Lab might be the way forward, although even organising this and ensuring a consensus of opinion may not be easy.
- Another way to enhance documentation might be to submit new articles / updates to existing articles through a mechanism like the open source contribution agreement.
Work is continuing on improving the mesh uploader – notably with the contributed updates from Beq Janus of the Firestorm team (see my Firestorm 6.0.1 review for details).
Further work could be done to improve feedback information given by the uploader, but this is currently seen as being more UI intensive, and outside the immediate scope of this updates.
4 thoughts on “2019 SL User Groups 33/2: Content Creation summary”
Re Wiki deprecation: Wow. I wonder if they have any idea what a tangled web of trouble they’d get themselves into if they try to replace the LSL Portal. The Knowledge Base is like a snowflake on the tip of the iceberg.
I missed the WUG where this was discussed, so still trying to gather the full context – but yes, “Wow!” was my reactions, with an immediate, “Wut?!” following it.
LikeLiked by 1 person
The free outfits for SL16B are a pretty good example of bad texture usage. Mulltiple 1024-textures, some of them applied to components roughly the size of the palm of your hand. And the way the graphics system works, that 1024 has to be downloaded to the user’s viewer, which then generates and stores a set of mipmaps, and picks the one to display based on the screen pixel size of the object. So you will have to do an extreme zoom-in to ever see that particular 1024.
That process is documented in the Wiki, but it took a bit of finding.
And the way some Wiki pages are linked together doesn’t help. Page A describes the original process, Page B describes a change, and there is no A -> B link. Is it any wonder creators don’t use new features?
In the end, I made some of my design choices for mesh clothing after testing what LOD did. One of those SL16B items switches to Lowest LOD at 100m, when it will be 2 or 3 pixels across: how many triangles does that LOD really need?
Does anyone, Linden, Mole, or ordinary user, really know how these things work? I’m not sure I do, but I did test.
>> Refresh of SL terrain texturing.
Interesting. I wonder if this an opportunity to look at the link to a fresh modern approach to terrain texturing, and ways to add in procedurally generated grass, trees, perhaps ponds and lakes not at “sea” level, etc. I like the Unity3D approach to this. This could really update the look of second life, avoid all the need for prim and mesh based ground cover plants and trees, etc.
Comments are closed.