The following notes were taken from the Tuesday, July 23rd, 2024 Simulator User Group (SUG) meeting. They form a summary of the items discussed, and are not intended to be a full transcript, and were taken from my chat log. Pantera videoed the meeting, and the recording is embedded at the end of this piece – my thanks, as always, for her work.
Meeting Overview
The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas.
Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.
Simulator Deployments
The SLS Main channel was restarted on Tuesday, July 23rd, 2024.
On Wednesday, July 24th:
The BlueSteel RC is due to (again) receive Summer Fun simulator update, which includes the initial Combat 2 updates from Rider Linden.
The remaining RC channels will be restarted.
SL Viewer Updates
Release viewer: version 7.1.8.9375512768, formerly the Graphics Featurettes RC viewer dated June 5 and promoted June 10th.
Release channel cohorts:
Atlasaurus RC (object take options; improved MOAP URL handling), version 7.1.9.9981869229, July 22.
WebRTC Voice RC, version 7.1.9.9688089989, July 1.
Maintenance B RC (usability updates / imposter changes) 7.1.9.9555137545, June 21.
Maintenance C RC (reset skeleton in all viewers), version 7.1.9.9469671545, June 14.
Project viewers:
None.
In Brief
Combat:
Rider Linden reminded people that Thursday, July 25th will be the final meeting of the Combat User Group, and will take the form of a combat session to take place on the Concord combat region (not Lexington, as previously indicated). Those wishing to participate and who have suitable Combat 2 weapons they are willing to share are asked to bring them to the meet-up.
The damage throttle is now off by default, the the default for the throttle is 1 point/6 seconds.
In addition: post death invulnerable agents should no longer be able to inflict damage directly. However sitting will remove that invulnerability.
The discussion on possible issues with llGetMass(), wherein a objects mass will not remain constant if it is resized and its density changed (via llSetPhysicsMaterial) to compensate has resulted in a new feature request – llOverrideMass(float new_mass) – being raised. This triggered a further discussion on mass / density calculations, specifically in reference to vehicles and passengers.
A general discussion on scripting, rezzing, updating object (/rezzer) contents.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.
The following notes were taken from my audio recording and chat log transcript of the Content Creation User Group (CCUG) meeting held on Thursday, July 18th, 2024.
Meeting Purpose
The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work. This meeting is held on alternate Thursdays at Hippotropolis.
Atlasaurus RC (object take options; improved MOAP URL handling), version 7.1.9.9620320242, June 27.
Maintenance B RC (usability updates / imposter changes) 7.1.9.9555137545, June 21.
Maintenance C RC (reset skeleton in all viewers), version 7.1.9.9469671545, June 14.
Project viewers:
None.
WebRTC Voice Update
Not strictly a Content Creation tool / subject, but of import to SL as a whole.
Summary
A project intended to move Second Life away from reliance on the Vivox voice service and plug-in, and to using the WebRTC communications protocol (RTC=”real-time communication”). Roxie Linden is leading this work.
Key benefits:
WebRTC supports a wide range of real-time communications tools in common use (e.g. Google Meet), supporting audio, video and data communications, and is thus something of a “standard” approach.
Offers a good range of features: automatic echo cancellation, better noise cancellation and automatic gain control, much improved audio sampling rates for improved audio quality.
Opens the door to features and capabilities to voice services which could not be implemented whilst using Vivox.
In addition:
LL are are of some of the security concerns around WebRTC voice (e.g. risk of eavesdropping, exposure of users’ IP addresses, etc), and is actively working to block these through the use of an internal proxy service.
LL will be looking to Linux devs to help give feedback on how well WebRTC is working on their Linux viewers
There is a Release Candidate viewer available on the Alternate Viewers page. Thus is expected to be the next viewer to be promoted to de facto release status.
This promotion is liable to occur ahead of the planned simulator deployments (see below), allowing time for TPVs to adopt the code.
Currently, LL is looking at August for a potential deployment across all of SL on the server-side.
This will follow the usual approach of roll-out to the simulator RC channels first, then to the SLS Main channel.
As a result, there will be some short-term issues around peer-to-peer, Group and ad-hoc voice connections between those on regions running the two different voice services (Vivox and WebRTC).
Depending on how the deployment goes (e.g. first to a single RC, then multiple RCs, then the SLS Main channel), it is hoped that any such issues will only be for around 2 weeks.
Viewers adopting the WebRTC code prior to or during this deployment period will be able to process both WebRTC and Vivox voice, so outside of the possible short-term issues during the back-end deployment mentioned above, voice services should not be interrupted for users.
Graphics / glTF
Transmission / IOR
Geenz Linden continues to work on Transmission and Index of Reflection (IOR). This will provide:
Both refraction and “blurry” refraction suitable for things like frosted glass surfaces.
Dispersion, allowing chromatic aberration, allowing the RGB channels to “separate out” based on a certain factor.
Volume, allowing an object surface to be tinted at different surface thicknesses.
There are still some bugs to be resolved with this work, after which it will be folded into the main viewer development branch, but is currently tied to the work on mesh import, but may be separated out.
PBR Terrain Painting
This is the next planned project for Cosmic Linden, and is in the very early stages of planning, so things are subject to potential change.
Currently, the thinking is:
The four PBR materials currently used for PBR terrain would remain available for use / painting.
The painting element would allow a user to define how these materials are mixed (via a paint map), rather than having to rely purely on the the existing height map.
The paint map is likely to initially be on the basis of one blended texture at region level (not parcel), although the resolution of the texture is still TBA at the time of writing.
The permissions for terrain painting will be based on ability to edit the height map (if you can alter the latter through the Region settings, then you’ll be able to use the terrain painting capability).
This effectively means:
Users who have terrain editing permissions will be able to use the existing terrain texture system, using the height map (terrain elevation) to define which textures are visible, and the “blending” between them. or – if provided at the region level – access the PBR terrain paint map and use that to define the terrain (e.g. where grass, dirt, rock, etc., appears), without having to use terrain elevation changes.
Use of the paint map will still be based of the X,Y positioning of terrain (as with the current height map), but all allow for actual blending of materials, rather than just creating transitional noise between textures set for different elevations, as with the height map.
Terrain painting will be a significant departure in how terrain texturing has been managed, requiring a new entity to be introduced. This is also still being thought through, but it is unlikely it will be a new asset type stored on the asset servers.
LL prefer to limit terrain painting to the four available slots at region revel, rather than allowing fully customisable swatches / slots at parcel level, as the latter presents “non-trivial issues” for terrain texture handling /loading.
Two further ideas being discussed in relation to terrain but not on the implementation road map are:
Implementing a means by which a prim can act as if it is part of the terrain, and inheriting the materials of the terrain on which it is placed, whilst allowing the geometry of the prim to be still be manipulated.
Instead of using terrain, provide a means by which “something else” (something created external to SL and then imported) as terrain. However, it idea is described as “more pie in the sky” thinking.
glTF Scene Import
No update, as Runitai Linden is out of the office.
(Non-Ambient) Lighting
Punctual lights is a glTF extension that has recently been folded into the main specification, defining the use of lighting sources (house light, table lamps, street lights, etc.).
Geenz Linden is working to implement punctual lights, but they will be tied to the node hierarchy for glTF scene imports.
Longer term, they hope to use the extension to enable punctual lights to render shadows (so, if your table lamp is a punctual light, it will cast shadows).
However, the extension is currently ambiguous as to what parameters should be used to define/ constrain such shadows, so this aspect of the work is liable to take longer to achieve, and may be dependent upon how other companies implement punctual lighting shadows.
In the meantime, Geenz does have some ideas on handling shadows from point and spotlights, which might leverage the work done on reflection probes.
In discussing the adoption of glTF punctual lighting, Geenz further noted:
There are some notable differences between glTF lighting and SL’s physically-based lighting model and also with the capabilities of lighting projectors as they are currently in SL.
As such, trying to unify punctual lighting with SL’s existing lighting / projectors could lead to content breakage.
Because of this, it is likely that as punctual lighting ins introduced, the existing lighting system will cease to be significantly enhanced, and pretty much left as-is, with the focus shifting to enhancing the punctual lighting system.
General Notes
Cosmic has also been completing work on support for PBR terrain texture transforms. This is s subset of the texture manipulation options (scale, offset, rotation, etc.), available with texturing prims, and is per material.
A request has been received to get planar face alignment to be functional for PBR, and this is defined as something the Lab wants to resolve “soon”.
Order-independent transparency is not something on the current road map, as it is seen as “too performance costly” to implement.
There is some potential for performance improvements / optimisations for mirrors.
Currently, whilst the mirror surface is planar, the reflection probe generates reflections for a full 180º in front of the mirror, not all of which might be required.
It might therefore be possible to adjust this to angles more appropriate for such viewers, making them slightly more performant – but the improvement will not be huge.
It should be remembered that mirrors can also be turned off (or have the update rate reduced) through Preferences by those feeling a mirror they are closes to and is active is too big a performance hit.
There have been multiple calls for Linden Water to be restored to its pre-PBR looks. Geenz noted that while making improvements to the appearance of Linden Water are not out of the question, the fact that Linden Water is not glTF compliant makes what can be done more difficult.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a gathering of people every week. They are taken from my list of region visits, with a link to the post for those interested.
The following notes were taken from the Tuesday, July 16th, 2024 Simulator User Group (SUG) meeting. They form a summary of the items discussed, and are not intended to be a full transcript, and were taken from my chat log. No video this week.
Meeting Overview
The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas.
Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.
Simulator Deployments
The SLS Main channel was restarted on Tuesday, July 16th, 2024.
On Wednesday, July 17th:
The BlueSteel RC is due to be updated with the summer Fun simulator update, which includes the initial Combat 2 updates from Rider Linden.
The remaining RC channels will be restarted.
Upcoming Simulator Updates
The simulator that we currently have on deck is Picnic, I cut that on Friday and should be getting it deployed onto Aditi in the next day or so. Next up is Barbecue. I believe that it already has a find text for notecards in it. I’m going to be taking another shot at llRotateAvatar.
– Rider Linden on upcoming simulator updates
SL Viewer Updates
Release viewer: version 7.1.8.9375512768, formerly the Graphics Featurettes RC viewer dated June 5 and promoted June 10th.
This work is in addition to the viewer-side Luau project.
Signal Linden has published a technical FAQ on the simulator-side project, addressing some of the most common comments / questions.
In Brief
Rider Linden reminded people that Thursday, July 25th will be the final meeting of the Combat User Group, and will take the form of a combat session to take place on the Lexington combat region. Those wishing to participate and who have suitable Combat 2 weapons they are willing to share are asked to bring them to the meet-up.
As per the most recent (to this meeting) TPVD meeting, the project to replace Vivox Voice with WebRTC communications protocol (RTC=”real-time communication”) will – subject to third-party viewer readiness – be deployed across the Main grid in August and the switch thrown.
Pepper Linden noted LL has deployed some map server changes which fixes issues with region surrounds in tile generation, as well as old stale tiles.
Part of this work has involved fixes to the Akamai cache retention period.
This should mean that rather than the system caching region tiles for many days and serving them to viewers, it should now only cache up to 12 hours. This means that in a worse case scenario map tiles displayed in the viewer should be no more than 24 hours behind.
The request to be able to call up map tiles via their UUIDs (like textures) was again made. This might be in the work queue.
Garfield Linden re-iterated his tangential project to bring maps.sl.com up to parity with Maps-in-the-viewer, and make it Mobile friendly. A Leaflets update for this has just been made, and will be expanded upon at the end Web User Group.
There is a reported bug in the core viewer code which causes glTF overrides to be cleared while the cache has not been yet saved by a neighbour region. As the simulator does not resend glTF data after the initial connection, the viewer’s object caches ends up with corrupted glTF cache entries from the affected region.
There appears to be an issue within llGetMass(), wherein a objects mass will not remain constant if it is resized and its density changed (via llSetPhysicsMaterial) to compensate. This resulted in an extended discussion on the subjects of mass and density under LSL adjustments.
The subject of implementing a variable walk speed on the simulator locomotion graph was again raised – an request raised a number of times at CCUG meetings. This was crossed with a discussion on avatar rotation by LSL in line with Rider’s hopes around llRotate Avatar and controlling avatar motion in general.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.
The following notes were taken from the Thursday, July 11th, 2024 Combat User Group meeting. They form a summary of the core items discussed and responded to by Lindens, and are not intended to be a full transcript.
Meeting Overview
The Combat User Group exists as a forum to discuss improvements to the Linden Lab Combat System or LLCS to better support combat in Second Life.
The core idea is to provide additional events and capabilities which sit on top of LLCS to provide combat creators with better tools with which to create better combat systems for their specific scenarios.
It is not intended to be a complete combat system in and of itself.
The meetings are the result of a proposal document on improving the native damage system in SL, written by Rider Linden, and which is the focus for both the meeting and any work arising from them.
These meetings are conducted (as a rule):
By Rider Linden, with the support of Kyle Linden.
On alternating Thursdays (rotating with the Content Creation User Group) at 13:00 SLT. Meeting dates are recorded in the Second Life Public Calendar and at this location.
In local chat.
Discussion topics, requests, etc., can be found on the SL Feedback Portal Combat Board.
The current iteration of server-side Combat 2.0 support is due to start deployment to the Bluesteel simulator RC on Wednesday, July 17th as a part of the Summer Fun simulator update.
Linden Lab has carried out some testing to ensure regions which do not have the Combat 2 updates will continue to operate the same way they do now.
Rider Linden is going to have the Concord and Lexington Combat regions moved to the Bluesteel RC so they are available for testing after deployment of the update.
Issues / feedback should be reported via the Support Portal Combat Board.
Feedback: How to Help New Users Discover Combat Opportunities in SL
Product Manager Kyle Linden asked for suggestions on the kinds of questions new residents might ask to in order to discover and participate in SL combat activities. Reponses included:
The basic questions: can combat / war games be played in Second Life? What kinds of combat are available? How do I find out more about them? How do I enrol? Where can I obtain weapons?
It was suggested a themed welcome hub with a selection of free weapons and some portals to newbie friendly combat regions could help solve some of these questions.
A themed welcome Hub might allow Combat Communities to apply for Community Gateway status and direct users signing-up through them to the “Combat Welcome Hub”.
A further suggestion was to have Combat added as a Search category.
Kyle Linden indicated LL was considering some newcomer friendly enhancements to linden Combat regions: teleporting to a safe parcel within them, where users might find a basic free weapon kiosk or random weapon spawner.
In support of this, it was suggested Linden Combat regions include a basic “Combat Experience” to ensure all permissions requests are either suppressed and / or correctly set and ensuring things like gestures for reload, semi/burst/auto, etc., are available.
It was also suggested that all entering the regions be required to accept the Experience in order to exit the safe parcel and participate in combat within the Linden Combat regions.
In Brief
As the initial Combat 2 updates have reached deployment, Rider considering folding the combat User Group meetings into the Tuesday Simulator User Group meetings.
Given there is already a lot of cross-over between the two, this makes sense.
The suggestion was made to conclude the Combat User Group with a combat meet- up on the Lexington region once deployment has completed. This would be the meeting currently scheduled for Thursday, July 25th.
It’s been reported that there is issue in which a damage object (generated by llRezObjectWithParams) collides with a non-avatar in the same frame, it does not actually do damage (see: Damage objects should send damage to the nearest recipient).
This is seen as a collision order issue (e.g. damage is always delivered to the first thing it hits – so this is a question of which gets the collision first).
Rider is aware of the issue, but is unsure how best to address the problem.
Additional Canny tickets:
Damage Over Time – this raises potential shortfalls with applying damage over time. This is currently marked as Under Review, pending consideration for future implementation.
Rezzing delays affect all scripts in an object – this is not limited to being a Combat-specific issue. This is being tracked, and it is hoped LL will have a fix available in a near-term simulator maintenance release.
Improved Mouselook for Combat and Immersion – this has been a topic of discussion at several combat meetings. As has been noted, this requires a pull request / code contribution from NiranV Dean (Black Dragon developer), who has stated he will endeavour to do so, once he has had the time to fine-tune and bug-fix the code some more.
The following notes were taken from the Tuesday, July 9th, 2024 Simulator User Group (SUG) meeting. They form a summary of the items discussed, and are not intended to be a full transcript, and were taken from my chat log. No video this week.
Meeting Overview
The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas.
Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.
Simulator Deployments
The SLS Main channel was restarted on Tuesday, July 9th, 2024.
On Wednesday, July 10th:
The BlueSteel RC is due to be updated with the summer Fun simulator update, which includes the initial Combat 2 updates from Rider Linden.
The remaining RC channels will be restarted.
However, at the time of writing a last-minute issue with Interest List updates meant the the Bluesteel deployment may be postponed.
SL Viewer Updates
Release viewer: version 7.1.8.9375512768, formerly the Graphics Featurettes RC viewer dated June 5 and promoted June 10th.
Atlasaurus RC (object take options; improved MOAP URL handling), version 7.1.9.9620320242, June 27.
Maintenance B RC (usability updates / imposter changes) 7.1.9.9555137545, June 21.
Maintenance C RC (reset skeleton in all viewers), version 7.1.9.9469671545, June 14.
Project viewers:
None.
2K Bakes On Mesh
Something that people might be excited to hear — we’ve officially started on 2k BOM support. It sounds like an easy thing to do, but it turns out that the service responsible for handling avatar baking hasn’t been touched in many years, and depends on an extremely old Linux viewer fork.
– Pepper Linden
Vir Linden has also pointed out that as well as updating the Bake Service (mentioned in Pepper’s comments) it is possible the entire wearable system layer system may also require updating. There is therefore no ETA at present on when this work will be completed.
The above led to a discussion on VRAM usage as a result of 2K textures on avatars, matters of Avatar Render Complexity (ARC – already well out of date and also ignores PBR), etc.
As a reminder, on PBR viewers, textures should have their resolution scaled to match screen resolution, should should help to some degree with VRAM use.
In Brief
It is possible that the implementation od glTF scene imports(once implemented) could lay the foundations for the updated of ARC as well as Land Impact.
There is apparently a potential issue with notecard searches and the number of returns generated, which could be in error. Rider Linden is looking into this.
There was an extended discussion on texture / PBR UUIDs, issues with overrides, etc. Unfortunately, most of this went clean over my head.
A new feature request for llRegex* functions has been raised and is being tracked by LL.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.
Nathhimmel: Lavender Fields of Madame Loutre, June 2024 – blog post †
The following notes were taken from my audio recording + the video recording by Pantera (embedded at the end of this summary) of the Third-Party Developer meeting (TPVD) held on Friday, July 5th, 2024. My thanks to Pantera as always for providing it.
Meetings Purpose
The TPV Developer meeting provides an opportunity for discussion about the development of, and features for, the Second Life viewer, and for Linden Lab viewer developers and third-party viewer (TPV) / open-source code contributors to discuss general viewer development. This meeting is held once a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre.
For both meetings: dates and times are recorded in the SL Public Calendar, and they re conducted in a mix of Voice and text chat.
The notes herein are a summary of topics discussed and are not intended to be a full transcript of the meeting.
Atlasaurus RC (object take options; improved MOAP URL handling), version 7.1.9.9620320242, June 27.
Maintenance B RC (usability updates / imposter changes) 7.1.9.9555137545, June 21.
Maintenance C RC (reset skeleton in all viewers), version 7.1.9.9469671545, June 14.
Project viewers:
None.
General Viewer Notes (Both Meetings)
The switch to working from multiple viewer RC branches to a single development branch is continuing.
This will mean in future there are likely to be fewer RCs in the pipeline than has bee the case for roughly the last decade (and sees the visible aspect of viewer development and release process swing back towards how it appeared prior to the switch to using RC channels).
Parallel tracking of viewer development will continue for a while, given the fact there are currently four RC viewers in flight.
The above change-over will not prevent contributions being accepted.
A new project intended to move Second Life away from reliance on the Vivox voice service and plug-in, and to using the WebRTC communications protocol (RTC=”real-time communication”). Roxie Linden is leading this work.
Key benefits:
WebRTC supports a wide range of real-time communications tools in common use (e.g. Google Meet), supporting audio, video and data communications, and is thus something of a “standard” approach.
Offers a good range of features: automatic echo cancellation, better noise cancellation and automatic gain control, much improved audio sampling rates for improved audio quality.
Opens the door to features and capabilities to voice services which could not be implemented whilst using Vivox.
In addition:
LL are are of some of the security concerns around WebRTC voice (e.g. risk of eavesdropping, exposure of users’ IP addresses, etc), and is actively working to block these through the use of an internal proxy service.
LL will be looking to Linux devs to help give feedback on how well WebRTC is working on their Linux viewers
Work has been on stabilising WebRTC and getting the viewer to RC status so that TPVs can look at it.
Overall, development work is in a “wrapping-up” phase.
Currently, LL is looking at August for a potential deployment across all of SL on the server-side.
This will follow the usual approach of roll-out to the simulator RC channels first, then to the SLS Main channel.
As a result, there will be some short-term issues around peer-to-peer, Group and ad-hoc voice connections between those on regions running the two different voice services (Vivox and WebRTC).
Depending on how the deployment goes (e.g. first to a single RC, then multiple RCs, then the SLS Main channel), it is hoped that any such issues will only be for around 2 weeks.
Viewers adopting the WebRTC code prior to or during this deployment period will be able to process both WebRTC and Vivox voice.
As a result of the Firestorm PBR release, Runitai Linden has been revisiting the issue of memory use in the PBR-enabled viewer code on lower-specification computers.
Geenz Linden is continuing to work on various glTF extensions, including glTF index of refraction (IOR) and transmission – with the work on the latter potentially being wrapped up.
Cosmic Linden has been tweaking the PBR terrain work for PBR transforms on terrain (one transform per material).
[Video 39:44-41:14] requests have been made for reflection probes in shapes other than cubes and spheres (e.g. cylinders, triangles, hemispheres) to account for more awkward interior space shapes (e.g. in roof areas). This is viewed as “highly unlikely” at the Lab.
However, the mirror capability may be extended to include sphere reflection probes at some point “if all goes well”.
PBR Terrain Painting
This is the next planned project for Cosmic Linden, and is in the very early stages of planning, so things are subject to potential change.
Currently, the thinking is:
The four PBR materials currently used for PBR terrain would remain available for use / painting.
The painting element would allow a user to define how these materials are mixed, rather than having to rely purely on the the height map.
E.g. if you have a paint map for a region, you’ll be able to blend the materials based on that, rather than having to use the height map, and define where areas of grass or rock or dirt, etc., appears on the ground.
The paint map is likely to initially be on the basis of one blended texture at region level (not parcel), although the resolution of the texture is still TBA at the time of writing.
The permissions for terrain painting will be based on ability to edit the height map (if you can alter the latter through the Region settings, then you’ll be able to use the terrain painting capability).
Terrain painting will be a significant departure in how terrain texturing has been managed, requiring a new entity to be introduced. This is also still being thought through, but it is unlikely it will be a new asset type stored on the asset servers.
[Video: 16:15-16:29] No decision has been made on making terrain painting open to scripted control.
Cosmic is open to feedback on how this might be used, if enabled (e.g. a scripted explosion leaving a detonation mark on the ground for a period of time).
In Brief
Reflections turn black when zooming in close is an issue which appears to be related to the use of mirror probes as well as “normal” reflection probes. If you are impacted by this, add your vote.
Auto-exposure under PBR (adjusting the general scene brightness when looking at one or more very bright objects in the scene), with people interpreting it as a bug, particularly with the release of Firestorm PBR.
It’s been suggested that a wiki page on how auto-exposure works should be produced, to which people can be pointed to help them understand what it is and how it works. Or potentially a debug setting or similar to disable (with a warning things may not display correctly as a result).
Canny feedback has been requested on issues being encountered / suggestions for related features (such as the setting noted above).
This led to an extending general discussion on lighting and rendering – please refer to the video.
RLV/RLVa adoption by the Lab is still in discussion and described as something the Lab wants to do, but it does represent an extensive change to their viewer.
As such, it is likely that as contributions are made, they will be pulled into the official viewer incrementally (presumably with some going behind debug flags until such time as they can be properly enabled).
Overall, it now appears the Lab does want to support the full RLV/RLVa feature set, rather than just a sub-set thereof as had been previously indicated as a possible route.
Opening the PBR terrain painting to scripted control led to a conversation on scripted weather systems – such as being able to change the ground appearance to match the season; having the ground appear to be covered by snow when it snows, etc. There have been requests for this, but it is not something the Lab is currently working on.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a gathering of people every week. They are taken from my list of region visits, with a link to the post for those interested.
Inara Pey: Living in a Modemworld 