Tag: Interest List

SL projects news week 44/2: server, group services, mesh and more

Posted on by Inara Pey

Quick Links

Server Updates

Deployments this week are being delayed some 24 hours, which means the main channel deployment will not take place until Wednesday 31st October, and the RX channels on Thursday November 1st. This has led to concerns that the main channel deployment / restarts may impact any Halloween events taking place across the grid on Wednesday 31st. Simon Linden promised to raise the concerns at an internal LL meeting taking place later on the 30th October, however, at the time of writing, the Grid Status page reports that the deployment will go ahead, starting at 05:00 SLT on the 31st.

In the meantime, the deployments for the week remain largely as previously indicated:

  • The main channel should receive the code currently on BlueSteel and Magnum. As mentioned above, the code has no externally visible changes but has some system level adjustments – release notes
  • LeTigre will receive a further update for the code currently running on it, which will include a number of bug fixes and pathfinding updates – release notes
  • On Friday 26th October, Simon Linden indicated to me that Magnum should be receiving the code planned for week 43 (the llSensor() problem has been fixed) which will include Baker Linden’s Group Services code currently on Snack, however, as of the Simulator User Group meeting on the 30th October, the final release notes for Magnum had yet to be published, so the update may still be in a state of flux
  • BlueSteel should get the same code as is on LeTigre.

Interest List

Andrew Linden has fixed a bug wherein some child prims in linkset fail to rez and he has carried out further work on performance issue he reported last time. This turned out to be an issue with the code which caused the simulator to send a full update of everything within view to the viewer each time an avatar within visual range moved. Understandably, on  crowded regions, this led to performance issues.

The code is in the process of being revised to ensure it only calls for “terse” updates to be sent to the viewer, which will help ensure more relevant information is sent to viewers when updating, which should reduce the performance hits.

Group Services

Baker Linden, speaking at the Simulator User Group on Tuesday 29th October, said that the server-side code for this project, which should improve the load times and editing abilities for very large group lists, seems to be working “moderately well” since the deployment to the Snack RC channel last week. However, some bugs have been found, Commenting on these, Baker explained that, “The group name, description, and other things don’t load right now on the Snack RCs.” However, the bugs have been investigated and fixes found, which should be merged into the code ahead of the planned deployments on Thursday November 1st. The fixes have also been tested on Aditi, where they’ve been found to induce a slight lag on group loading.

For the time being, testing this now code continues to require a dedicated SL project viewer (available for Windows, Mac and Linux), until such time as issues with the SL beta viewer code can be fixed and merges with viewer project code resumed / made available to TPV for integration.

Avatar Baking

Work is still progressing, Nyx Linden confirmed, talking at the content Creation User Group on Monday 28th October. How far down the road the work is, is unclear. The server-side of things will apparently be using the code being developed for the viewer, and it is this which is the focus of attention for the present, as has been the case for some time.In talking to TPV developers on the subject the last time the matter came up, Oz Linden confirmed LL’s plan is still to give TPVs “at least” 2 months (eight weeks) notice prior to anything being rolled out for testing, in order to give TPVs sufficient time to incorporate the code into project viewers of their own and assist with the overall testing.

SL Issues

Mesh Alpha Issue

Theresa Tennyson demonstrates the skinned mesh / alpha issue

Also during the Content Creation meeting, a problem with alpha textures as applied to worn skinned meshes was brought up. Theresa Tennyson demonstrated the issue during the meeting, which somewhat resembles the old invisiprim  / alpha issue.

Siana Gearz suggested two possible causes for the issue, “[The] first is that rigged mesh transparent surfaces appear to be drawn before prim transparent surfaces. [The] second issue is that the shader apparently writes depth for whole fragment, not just for relatively in transparent pixels.”

Nyx Linden requested a JIRA item be raised for the issue, again highlighting the problem with the recent JIRA changes, in that outside of those with access privileges to the new system, no-one could actually confirm if a JIRA had already been raised.

ETA 31st October: Seems a public JIRA on the matter is available – see MartinRJ’s comments which follow this article. Many thanks, Martin!

With thanks to Theresa Tennyson for the Simulator UG meeting transcript

SL project news: week 43/4: server updates

Posted on by Inara Pey

Week 43 Deployments

Main Channel

Tuesday October 23rd saw an update to the main channel which should have minimal impact on things, the changes having previously been on the Magnum RC channel. LL have been monitoring the deployment and have seen no adverse impacts.

BlueSteel RC

The BlueSteel RC channel received a further update to the current server maintenance project aimed at general stability improvement.

LeTigre

LeTigre is currently the focus of the server modernisation project, and as such received further updates to the deployment of Havok 2012.1. This means that mesh vehicles will continue to be unable to cross from LeTigre into regions running on other server channels for the time being.

As previously reported in part one of this week’s project news, LeTigre contains an updated cURL library which may cause problems for services using an external website for frequent data updates. The issue affects llHTTPRequest.

Essentially, the problem is that until now, the cURL library used by LL uses an explicit call to ensure data being returned from an external web service (such as information relating to the health status of breedable animals) is “fresh” data, rather than anything which may have been cached along the way. As such, specific functionality hasn’t previously been required within LSL to ensure this is the case.

However, The new cURL library deployed to LeTigre no longer attached the explicit call (technically a Pragma: no-cache header) to outgoing requests. This means that information being returned as a result of a call to an external service may in fact come from data cached along the way (such as from an intermediary server). Obviously, receiving “old” data would not be good for things like breedables, which could end up dying.

To overcome this, LL have added a new flag to the llHTTPRequest function to achieve the same result as used to be achieved via the old cURL library attaching the Pragma no cache “request”. In the meantime, anyone with breedables or other services which rely upon frequently updated data from an external web service have been advised to test their products on LeTigre.

Magnum RC

The Magnum RC channel was to have received a series of bug fixes, together with Baker Linden’s code for large Group Services. However, a showstopper issue was discovered with llSensor(). As a result, the release was rolled back and replaced with the BlueSteel deployment.

Also to have been included with this release is a new capability allowing the simulator to report information about script permissions granted to objects within a region. This capability requires an update to the viewer in order to be used (the code for which is currently held-up due to the beta viewer issues). Once the viewer code has been released, the new capability will allow users to list all items in a region to which they’ve granted permissions (such as items which have been granted animate permissions) and, if required, revoke them.

Please use the page numbers below to continue reading this article

Pages: 1 2

SL project news: week 42 / 3 – server news

Posted on by Inara Pey

There is a lot going-on server-wise at the moment, so best to break it down by heading.

Server Rebalancing

The Lab is currently engaged in a rebalancing exercise in an attempt to put neighbouring regions on the same server and generally do a logical organizing of the grid to help improve various aspects of performance. Speaking at the Server Beta User Group on Thursday 18th October, Oskar Linden explained that there has been a lot of moving around (in terms of regions) within and between the Lab’s co-location facilities, and so the re-balancing is warranted and needed.

This work takes time – a rebalancing operation earlier this year took around 6 weeks to complete. It requires that regions are organized into groups and then generally moved twice: the first time to a temporary sever, the second to the target machine, each move requiring a reboot, so people may notice additional and unexpected restarts to regions they are in as the work progresses. Two moves are required because the server topology is so tight, it often isn’t possible to move regions directly from one server to a target server, so an intermediary is required.

While this work will take time to complete, the result should be improvements in stability and performance with the likes of teleports, etc, and even improved region crossings.

More on the Server Deployments for Week 42

  • Main channel: Oskar provided some more information on the main channel update of Tuesday 16th October, saying, “The main channel got a tweak this week, but it was a really small change, and no sim code got changed. We recognised that we had some inefficient SQL queries where large groups were concerned, so we optimised them, and the effect was quite noticeable. The databases are more responsive [and] this helps at all levels.” He went on to clarify that these changes were not Baker Linden’s Group Services code changes, after some in the meeting appeared to think this might have been the case
  • BlueSteel received the updates which were tested in the network pile-on test in week 42. At the time, I commented that teleporting seemed a lot faster, but that might have been a placebo effect of being on Aditi. It was. Commenting on the test, Oskar said, “There were no simulator changes in that test code. We were just testing backend tweaks.”
  • Magnum received no update per se, as previously reported, but was merged with trunk and then redeployed
  • LeTigre received the biggest update, which included new LSL functions ad updates, and most importantly of all, a new version of Havok (see below). Of the LSL functions, Maestro had a warning about the new OBJECT_PATHFINDING_TYPE parameter in the pathfinding command llGetObjectDetails, “We misspelled a constant, OPT_UNKNOWN, so we plan to fix that.” The fix will probably be next week.

Havok

As mentioned above, Havok on LeTigre was updated to version 2012.1. The update enables Havok’s built-in terrain optimisation and should lead to improved performance as a result of the physics shape of the terrain being simplified. Prior to the deployment, there were concerns that it would lead to issues with mesh vehicles trying to cross between regions running different version fo Havok, as has previously been the case.

As reported in part one of this update, these concerns led to Andrew Linden contacting the deployment team in LL to check whether it would be possible to ensure none of the Blake Sea regions remained on LeTigre while two versions of Havok running on the grid to help alleviate at least some of the pain people would feel when using mesh vehicles there. This apparently happened, whether it was before or after the deployment is unclear, as some people did report issues following the roll-out. There was also a little confusion as to what had been swapped where.

At the Server Beta meeting, Oskar gave the impression that all Blake Sea regions were on LeTigre. However, at the Simulator User Group meeting on Friday 19th October, Andrew Linden indicated that records showed none of the Blake Sea regions are running on LeTigre, although they are spread across the other channels. Given that there were (according to Andrew) around six Blake Sea regions running on LeTigre to start with, it would appear to make sense that they have been rotated off to another channel, rather than attempting to rotate all of Blake Sea on to LeTigre.

Please use the page numbers below left to continue reading this article

Pages: 1 2

SL projects update week 42 / 1

Posted on by Inara Pey

Server Updates

The main channel deployment took place as planned on Tuesday 16th October. As previously indicated, this was the code deployed to the BlueSteel RC channel in week 41 (essentially an improved database query that should help with the back-end system load).

Of the Release Candidate channels, these are due to be updated on Wednesday 17th October as follows:

  • Magnum – will not receive an update, but will continue to run with the code deployed in week 41, probably in the same configuration
  • BlueSteel – will get code that’s almost the same as the main channel, with some OS-level configuration changes that shouldn’t be visible to anyone
  • LeTigre – will be getting a minor update to the Havok library which is mostly about getting our servers to build under Visual Studio 2010 on Windows and autobuild on Linux.

The LeTigre update will use “slightly newer” versions of the Havok libraries, so concerns were raised at the Server  / Sim meeting on Tuesday 16th October as to whether this may lead to a resumption of the problem with mesh vehicles being unable to travel between regions running different versions of Havok.Andrew Linden confirmed this might well be the case for mesh vehicles moving between LeTigre regions and other regions following the deployment.

To help reduce issues with situations like this arise, it was suggested that areas such as the Blake Sea regions are either removed from the RC channels, or placed on the same channel. While this would not solve the problem grid-wide, it would reduce the impact somewhat for people using mesh vehicles in these regions. A query was put to the LL deployment team on this by Andrew Linden, and they  agreed to try to make the Blake Sea regions more homogenous by ensuring they are all on the same channel.

SL Viewer

A further stability test build for the beta viewer was made on Friday October 12th, and reached the download page on Tuesday 16th (3.4.1.265898 – release notes) after being cleared by QA. This should be the last stability test release and should see the OK for code merges to resume. Merges and release priorities are still being looked at, and speaking at the Open Dev meeting on Monday 15th October, Oz indicated that there are “a few open source contributions in the pipeline that are in the mix”, as well as the anticipated LL merges such as the Steam code, Monty Linden’s HTTP library updates, Baker Linden’s Group Services project code, Apple OSX Mountain Lion support (including gatekeeper compatibility), etc.

Kelly Linden reports fixing SVC-7870 (Edit Linked Parts isn’t returning creator/owner), but given the current backlog, it may be a while before this makes it through to a beta  / release viewer.

Avatar Baking

The aim of this work (Project Sunshine) is to improve issues around avatar baking and to eliminate bake fail issues. It will primarily focus on moving the emphasis for the baking process from the viewer to a new Texture Compositing server. The viewer will retain some elements involved in avatar baking – the actual baking of the avatar shape (i.e. shape values and IDs) will still take place on the viewer side, for example.

As of Monday 15th October, no major news. Commenting at the Content Creation / Mesh Import meeting, Nyx Linden said, “Still plugging along at it :). It’s a complex project with many moving pieces, we’ll let you know when there are updates, and I will definitely be asking for beta testers here when we’re ready for feedback”.

Interest Lists and Object Caching

The focus of this project is to optimise the data being sent to the viewer, information already cached on the viewer and the manner in which that data is used in order to ensure it is used more efficiently so that things rez both faster and in a more orderly manner than is currently the case.

Interest lists and object rezzing: ironing-out the bugs, wherever they are

Andrew Linden continues to iron-out the bugs in the interests lists project, including one in the main viewer codebase wherein after crossing a region boundary the connection to the region you were just in will get reset after about 60 seconds. This is impacting the interest lists work and requires resolving, so Andrew is currently focused on trying to sort it out. A problem has also been reported with objects rezzing in the test regions on Aditi (e.g. Ahern) when moving through them in a vehicle, and will be looked into.

Pathfinding

A question was raised at the Content Creation / Mesh Import meeting on the 15th October as to why a 1-prim pathfinding character  has a land impact of 15. The reason for this is due to the increase physics load on the character. As previously covered, while this may seem harsh, it actually means that characters with a much higher prim count will also have a land impact of 15 (for example, a 30-prim character will still only have a land impact of 15), unless other factors (such as streaming cost) come into effect.

There are a couple of other issues with pathfinding characters which are being (or are about to be) looking at:

  • A bug whereby copies of single-prim characters only have a land impact of one (not 15). This problem is being addressed under PATHBUG-194.
  • A problem wherebypathfinding characters suddenly appear to “fly away” when adjusting your camera position, almost as if they are suffering from lag, and then reappearing there they should actually be (I gather this tends to happen when looking at a pathfinding character, which is following a set path then turning the camera away and then back again). Andrew Linden believes the problem is related to interest list updates, and will be looking into it.

Mesh

The patch to enhance the mesh uploader when dealing with rigged mesh items was discussed at the Content Creation Mesh Import group meeting on October 15th, with Nyx expressing interest in the idea, and agreeing with a suggestion that the patch needs to be formally submitted to LL’s bit bucket repo applied to a cloned version of the development viewer, supported by a JIRA outlining the patch and with a link to the repro.

Mesh uploda enhancement: suggested that it is submitted as a patch to LL

SH-3055 is a bug relating to mesh uploads which has been around for a while, but which appears to be affecting more people of late. With it, mesh uploads fail without any error message or warning on clicking CALCULATE or UPLOAD on the mesh upload floater. The issue is hard to track down (or even reproduce) as it doesn’t occur with any consistency. Either the upload works, or it simply sits as if waiting for something – whether it is waiting for data to be returned by the server, or whether it is receiving information and failing to action upon it.

Darien Caldwell and Nicky Dasmijn have been working with a debug viewer in an attempt to pin the problem down, but so far without success. One school of thought they are pursuing is that it is a problem with the viewer’s cURL wrapper (which is also thought to have been responsible for the recent crash issues being experienced in the beta viewer). The thinking behind this is that the problem appeared to come about with the introduction of a multi-threaded cURL in v3.2.5 of the viewer – with 3.2.4 having exhibited no major issues with uploading.Nyx Linden has stated he’ll take the problem to the team work on cURL to see if they can identify anything.

Materials Processing

No further updates. When talking to Geenz Spad and Oz Linden on Tuesday 16th October, Geenz could only say, “There’s not much to really report on materials for the time being unfortunately, but when there is something I’ll be more than happy to tell everyone.” Oz then added, “We’ll do more than tell you – we’ll give you something to play with :-)”.

Network Pile-on Test Update

Commenting on the thread for the pile-on test, Oskar Linden said: “All of the tests passed and the code will be going to RC next week. Thank you all for your help!”

With thanks to Baz deSantis for information on the Sim / server Group meeting.

SL projects update week 41 / 2

Posted on by Inara Pey

This item is a follow-on from part one, published earlier this week.

More Server News

At the Thursday Beta Grid User Group meeting (Thursday October 11th), and prior to the network optimisation tests, Oskar gave further news in the  serve deploys for week 41. On Tuesday 9th October, the main channel received code previously on BlueSteel, which in keeping with Simon Linden’s comments at the Monday Sim / Server UG meeting, Oskar referred to as being, “A pretty small release, just some server crash mode fixes; stability ++.”

On Wednesday October 10th, BlueSteel and LeTigre received a fix to some database queries that were really slow when accessing really large groups (note these were not Baker Linden’s Group Services code, that is being looked at as a deployment in week 42).

Monday 16th October may see some restarts on the grid in order to shuffle some regions onto new hardware, with the servers having more and faster CPU cores, which will increase the number of simulators running on the new servers, but they’ll be running on faster CPU cores.

Interest Lists and Object Caching

The short-version update for this comes from Andrew Linden, speaking at the Server Group meeting on Friday 12th October, “I thought I’d have something working this week… it isn’t quite working right. You can see it not working on Ahern on Aditi…” (!)

Interest list changes: easing the pain of random rezzing

He went on more seriously to explain that while the new code is working correctly for the most part, and that rezzing orders should be improved / faster, there are some problems with objects which should be in view of an avatar not showing up and a major issue around teleporting into high ground.

When the latter happens, you effectively arrive “underground” (presumably at the default “ground level” for the simulator  – 21 metres in the case of unterraformed land). The simulator then calculates where you should be and moves your avatar appropriately. With the new code, this has the effect of breaking the server’s notion of the camera – where it is and what it can see – which is used to figure out what objects to send to the viewer. This means that the camera itself cannot be moved or updated.

There have been some performance tests on an older version of the code, which have been mixed, as Andrew also explained, “here were two performance tests run on an earlier version. One test (mostly empty region with about 30 avatars running around) showed a slight decrease in performance… about 5% worse. Another test (crowd of avatars NOT looking at a pile of dynamic objects behind them) showed about 40% improvement (less time spent running the interest list). So I went back to the code to try to fix the first test, and I think I’ve got something that will be as good or better all around.”

The code will also see changes as to how the camera behaves and in the resultant level of detail. Andrew is currently working on limiting the distance the camera cam be moved away from the avatar. Note this is not limiting Draw Distance, but limiting the distance the camera can be freely moved independently of the avatar. He’s considering 128 metres to be the likely range. There are two reasons for this.One is to prevent the camera wandering into regions which are more than one neighbouring region away, the other is because as the camera moves laterally, detail levels degrade, because object detail is tied to the avatar’s position (hence why, when you zoom a great distance, buildings and objects may only appear to partially rez, etc.). Under the new system, object detail will be tied to the camera, so that little degradation is experienced. However, in order for this to work, the camera must be kept within a reasonable distance of the avatar; if it is moved too far, the detail will start to degrade once more (presumably because of the volume of data the viewer is trying to handle).

Mesh Deformer

On Thursday 11th October at the Open/Dev meeting, Darien Caldwell outlined her ideas for using base shape info exported from Second Life when uploading rigged meshes.

If this works, it will essentially mean that rather than being restricted to using a default base female or male shape when uploading rigged meshes, creators will be able to download a human shape as an XML file (permissions allowing), and then specify this shape when uploading rigged meshes.  The basic code for handling the upload with specific avatar shape information has already been added to the deformer by Qarl Fizz, so Darien is focusing on the best way to use it, her work going into a fork of the existing Mesh Defromer project viewer.

Avatar shapes can currently be exported from a viewer via DEVELOP -> AVATAR -> APPEARANCE TO XML (again subject to the permissions system). This saves the avatar shape data as an XML file, which contains the settings from the appearance sliders, and which is automatically saved to your computer (generally to  C:\Users[USERNAME]\AppData\Roaming\SecondLife\user_settings for Windows).

To associate an avatar shape .XML file with a mesh, Darien is proposing a further revision to the mesh uploader floater, and has provided an early mock-up as to how it might look.

New option to associate an avatar shape XML file with a mesh on upload (image courtesy of Darien Caldwell)

More work is required the flesh-out this idea, including, as Oz noted at the Open/Dev meeting, making the shape export option more obvious for people to use, which will more than likely see it moved out of the Develop menu, wherein it is currently nested. The .XML file itself is not suitable for use directly in most 3D modelling programmes, so how the exported data might be used with these when creating mesh items remains to be seen. nevertheless, if successful, Darien’s approach may offer a more fine-tuned solution to developing mesh clothing to a range of shapes.

Other items

Viewer and FMOD

The use of FMOD has been the subject of much discussion within the TPV/Dev meetings of late. FMOD is used within the sound system for the Viewer, and until now, Linden Lab has provided a script which pulls library files from an FMOD repository for use in viewer builds. However, following what appears to have been a clean-up of their archives, FMOD have removed the some of the legacy files required for this, as reported in JIRA OPEN-150.

Some viewer developers have already started using FMODex within their builds (e.g Singularity 1.7.0+), which also addresses issues with sound quality as well. Other TPVs are looking at possibly integrating this work into their builds.

It currently appears as though Linden Lab themselves are looking to integrate FMODex, as they see this very much as something which needs to be addressed. Speaking at the TPV/Dev meeting on Friday 5th October, Oz Linden stated: “I got around to forwarding the JIRA on that to our engineering manager for Second Life, and he agreed with me that it is something we should definitely do something about. I’m not sure what the time-table on that will be, it’s going to go into the hopper for the next ‘Things we should do something about, what priority are they compared to all the other things we should do something about’ meeting, which happens weekly.” While openAL has also been suggested as an alternative, it does seem more likely that FMODex will be adopted, something which was hinted at by Oz when talking at the Open/Dev meeting on Thursday 11th October.

Teleport Timeouts

Baker Linden has been looking into the issue of teleport timeouts, and has managed to pin down one cause as a reproducible bug. He’s not sure as to whether it can be fixed, and is currently investigating further as to why it is happening.

 

SL projects update week 40 / 2

Posted on by Inara Pey

Server Deploys

As many are aware, there was a major error in this week’s LeTigre Release Channel deploy. Apparently, the root cause of the problem lay in the server-side prim account code, which Simon Linden describes as having “blown up” on the LeTigre RC channel. This resulted in a large number of items (including partial builds) being returned to people’s inventories as a result of regions being seen as “full”. The problem required a two-stage recovery:

  • LeTigre regions were rolled back to a state prior to the faulty deployment, and were then updated with the BlueSteel code also deployed on Wednesday October 3rd. This helped to determine the extent of the damage (a total of some 1200 regions)
  • The regions damaged by the land impact miscalculation were then restore to a state prior to the roll-out of the original faulty LeTigre code. These had to be restored manually, which took a considerable time

There is further post-mortem work going to to try and discover why this error did not reveal itself when the code deployed to LeTigre was being tested on Aditi, and whether there is anything specific to the regions impacted by the error which may have triggered it. Thought is now also being given to managing large scale region restorations, despite this being the first time there has been such a massive issue of this kind occurring across the grid.

Current RC plans for next week call for the same maintenance release to be made to all three RC channels, which Simon Linden describes as, “Mostly internal changes but [which] does include a minor update for the physics engine library … It’s almost all updating libraries … we’ve been using a fairly old set of compilers and such to make some of the development builds of the servers, and this brings us to more recent code.” Further details on the deploy should be available next week in the Second Life Server section of the Technology forum.

SL Viewer

As indicated in part one of this report earlier this week, problems have continued with the Beta viewer code and high crash rates. Work has been ongoing to try and locate the probable cause(s), some of which included the temporary return of tcmalloc. While not actually a cause of the crash issues, having tcmalloc disabled was affecting efforts to reproduce the problems. a beta release was made on the 3rd/4th October (3.4.1.265434), which is proving to be a lot more stable than previous versions, and which happens to have tcmalloc enabled.

The current plan is for a further beta release to be made, most likely on Monday 8th October, which should see tcmalloc turned off once more (if not removed). Should this also prove to be stable, the fixes it contains will be merged back into the development viewer code, and this will clear the way for clearing the backlog of code merges for both the beta and development viewers. It may also see a further 3.4.1 release version of the viewer being made.

Among the projects awaiting merging into the development and beta viewer code are:

  • The Steam support changes, which have been available within a development viewer stream, and which are described as “mostly cosmetic”. There is apparently a version of the viewer on Steam, but it is not available for general viewing / download, and is presumably there for testing purposes
  • Monty Linden’s HTTP library (texture fetch) code
  • Baker Linden’s Group Services project code
  • Apple OSX 10.8 Mountain Lion support work, including gatekeeper compatibility
  • Bug fixes and further regionalisation work.

Previous plans for these releases called for them to be made under the 3.4.2 code base. While this wasn’t discussed at the TPV/Dev meeting, one assumes this is still the case. However, speaking at the TPV Dev meeting on Friday October 5th, Oz Linden indicated that the order, etc., in which waiting merges will be cleared hasn’t been fully defined, and will be the subject of internal conversations next week at the Lab.

Avatar Baking Project

Bake fail: a familiar problem for many

There is still no major news on this project, although work is continuing both on the viewer and on the server code.

The plan remains to provide TPV developers with access to the viewer code at least 8 weeks ahead of any initial deployment of the server-side code to an Agni release channel. This is to allow TPVs time to merge the code into their viewers and participate in ongoing testing of the new service.There is a possibility that that viewer code will be available sufficiently well ahead of things in order for TPVs to be able to use it alongside the testing on Aditi (beta grid), depending on the status of the beta grid tests and how development of the viewer code progresses.

Please use the page numbers below left to continue reading this report

Pages: 1 2