More on materials processing

Materials processing was further discussed at the Content Creation Informal User Group meeting on September 11th. During the meeting, Oz confirmed that normal and specular maps will have their own rotation and offset controls from the start, which stands in difference to thoughts that they would initially be locked to the same rotation, etc., as the texture map used on an object or object face.

Materials processing: using a normal and diffuse (texture) map to generate a 3D effect on an in-world wall – coming to SL in the near future

This means that the new materials processing maps will have the same positioning and scaling properties are currently available for texture (diffuse) maps, namely:

  • Mapping: one of Default or Planar
  • Horizontal  and Vertical Repeats: number of repeats of the image over the surface (used only in default mapping)
  • Rotation: degrees clockwise by which the map is rotated
  • Repeats per Metre: number of repeats of the image per in-world meter of the surface (used only in planar mapping)
  • Horizontal and Vertical Offset: distance in meters the image is shifted right (horizontal) or up (vertical) on the surface.
Options to be used by normal and specular maps as well as by textures

This obviously increases the amount of control content creators will have over the additional maps once the new capabilities are live, but it does open up more issues around incorporating the capabilities into the build floater. Thus, it was the build floater which once again became the focus of the conversation during the meeting.

How the build tools are presented to users has already been the subject of much broader consideration within the CCIIUG, although that discussion appears to have stalled for the time being. The materials processing process, however, requires a more focused examination of the build floater in terms of enabling the additional controls without either making the existing floater too large or overly complicated.

As such, two ideas were briefly discussed at the meeting, and further input to them both will doubtless be sought. The first involved having the additional options contained within the existing Texture tab as sub-tab options, while the second involved having all of the mapping options (Texture/diffuse, normal and specular) and their associated positioning and sizing options moved to a dedicated floater of their own.

Of the two options, both have merit and pitfalls. Sub-tabs mean keeping everything together on a single floater, but could lead to things becoming cramped or possibly confusing. Splitting between two floaters would provide more space with which to present options and controls, but could lead to a reduced in-world view should people find they need to work with both floaters open.

Given the small number of attendees at the meeting, neither option was discussed in-depth, and so, as mentioned above, this is liable to be a subject which is returned to in future meetings.

Rendering Pipeline Changes

As a part of this project there will be changes to the viewer rendering pipeline. While the project is still some way off in terms of delivery, Oz Linden used the TPV/Dev meeting of September 7th to advise TPV developers that they will need to ensure they are current with the 3.3.4 rendering code, which will form the basis for implementing the materials processing system changes.

Oz also indicated that while it would be “quite a bit of time” before the project reaches a development or beta viewer because the overall specification is not yet frozen (but is, in his words, “Very, very slushy”), it is hoped that a project viewer would soon be available to allow the new materials processing capabilities to be seen and tested.

In referencing the release of a project viewer, Oz advised against anyone trying to pull the code and using it in any viewer intended for wide distribution. This is because it is possible the material processing capabilities may change in very significant ways before they are ready for more general release, leaving the code presented in any project viewer as limited in both value and function.

Accounting System Costs

It is still unclear whether the new materials processing system will fall under the new land accounting system in terms of server and rendering costs. While questions have been asked in this regard, no definitive answers have yet been furnished by LL. This again is potentially due to the matter still being under consideration and the specification itself still being revised as impact and changes are considered.

Discussions on the project will doubtless resume at the next CCIIUG meeting.

Related Links

JIRA: feedback from the Lab

The dust is slowly settling from the recent announcement vis the effective closure of the Public JIRA for bug and issue reporting and the implementation of the simplified Bug Tracker approach and associated changes.

Comments passed from front-line staff by Linden Lab make it reasonably clear that the new approach to bug reporting and management has impacted more than just those users who have in the past been actively and positively engaged in the Lab’s JIRA; the Lab itself is undergoing something of a shift in how issues are handled, and that is it likely to be a few weeks before matters settle down internally.

JIRA change: seen as a disappointing move by many

The Lab is also adamant that the overall aim of the change is to try an improve the utility of the bug reporting and management process from their own perspective – part of which was to eliminate the issue of having the JIRA used either as a forum for discussion and / or for posting irrelevant / angry statements, neither of which were seen as assisting the process of problem management and issue resolution. However, there has been an acknowledgement in some quarters as to whether or not the new system will increase or decrease the effectiveness of bug tracking  / management over time is an open question at the Lab, and that depending upon how the new system is seen to work over the next weeks / months, further changes may be made.

“JIRA Support Groups”

During the TPV/Dev meeting on September 7th, Oz Linden indicated that there are two “user groups” which are being established in relation to the new changes, and which the Lab will use to allow those residents with a demonstrable need to access a JIRA system and who are known to do so “responsibly” to have greater access to the new system.

Commenting after it became apparent during the meeting that some in attendance already had greater access to LL’s JIRA than others (including the ability to still comment on JIRA items), Oz said:

It should be noted that not all of you have exactly the same privileges. As part of this change [to the JIRA system] I created some access groups that do have somewhat deeper access … I haven’t actually figured out exactly what got set-up in the end … so be a little careful about asserting that, “Anyone can do such-and-such”, because if you’re in the active contributors’ group or the support helpers’ group, you have privileges other people don’t have … As I said, these changes have only been in effect less than 24 hours now [at the time of the meeting] … because there are a couple of levels of indirection involved, it’s not trivial to figure out what privileges a given person has – which is weird, but there you go … So, I have put in place a mechanism that I hope will make it easier for those of you who are actively collaborating with us on making the world better to continue doing so. It will probably take some time for all the bugs in that accommodation to be worked out.

Later in the meeting, he indicated one of these two groups, the “active contributors’ group” is being aimed towards the likes of TPV developers and those who have contributed to Second Life in terms of code and fixes, etc., in order to try to ensure they continue to have access to the new system which is beneficial to them (and more particularly, to LL) in order to better resolve bugs.

Similarly the “support helpers’ group” will be overseen by Alexa Linden and will comprise those who have demonstrated their value in assisting with the broader triage process (such as identifying duplicate issues, recognising where short-term workarounds for problems may exist, etc.).

Both groups were referred to as having greater ability to search reports in the new system, although the precise function and capabilities of these groups is liable to mature alongside the new system. While some people have already been added to the groups, this has been done as something of a “first pass” and appears to have been based upon first-hand knowledge of those involved. How additional people will be added to each of the groups is not entirely clear, although it is evident that in order to qualify for consideration, an individual must have a track record of positive and beneficial engagement in the JIRA process to triage and / or resolve issues.

Also during the meeting, Oz encouraged TPV developers who are concerned about the negative impact of the change and who have “Legitimate use cases that serve the needs of Second Life in general and Linden Lab in particular,” which may not be met by the new system, to write them up “In non-emotive form, … [but] in terms of how they are useful to Second Life residents and how they provide utility to Linden Lab … a calm exposition of the value to Linden Lab of doing something different would be.”

Forum Discussion Option

The JIRA situation was also raised at the Simulator User Group Meeting, also held on September 7th, Simon Linden put forward a suggestion that perhaps the forums could be used in some capacity. He was encouraged by those attending the meeting to pass the idea back to the Lab itself, with Toysoldier Thor suggesting a new Forum category of “Post-JIRA Forums” to facilitate general discussions. During the Content Creation User Group meeting held on the 10th September, Alexa Linden further indicated that the possible use of the forums was being considered.

Going Forward

The debate on the positive / negative aspects of this change are liable to continue for some time to come. That steps were taken to create two new “JIRA support groups” ahead of the launch of the new system tends to demonstrate that some within LL were not blind to the part played by users in the overall management and resolution of bugs. The hope appears to be that these new groups will offset the more negative aspects (lack of access, ability to contribute, etc.), presented with the launch of the new system.

Whether this proves to be the case will come down to how effectively the groups are managed, the level of access those within the groups are given, and whether or not the new system itself achieves the level of improved utility in the reporting, triaging and resolution of bugs the Lab hopes will be the case. Currently, it would appear that none of this is liable to be objectively known for the next several months.

Related Links