Not much going on in scripting right now. Various changes and new functions are winding their way through QA and the release channels. But, not much new information. Also, Kelly Linden did not have the usual Scripting User Group Meeting this Monday.
The new PRIM_SLICE in llSetPrimativeParams() is in testing on Magnum Release Channel. The Magnum release is having problems with group chat. So, it is unclear whether that feature will roll to the main channel tomorrow or not. I can’t image that llSetPrimativeParams() is causing group chat issues. But, the Lindens are testing interactions, so it may not make it.
The new HTTP_BODY_MAXLENGTH in llHTTPRequest() is also in Magnum.
The new function llGetRegionAgents() is also in Magnum.
Hopefully these will get some fixes and remain in Magnum. We should find out tomorrow.
The Content Creation and Mesh Upload group had a short meeting. Nyx Linden is out this week, vacation I think. Vir Linden ran the meeting. There was one interesting question.
For a simple mesh, triangles in the same mesh and with the same material, when textured with a transparent texture, appear to be rendered in the order the triangles appear in the Collada file. This can be used to overcome the alpha-sorting-glitch. Would it be correct to assume this is because the triangles are submitted to OpenGL in that order? If so, is the rendering code guaranteed to always submit triangles to OpenGL in the order they appear in the Collada file, in particular for more complex meshes? Drongle McMahon.
You probably know that we have problems with clear/transparent textures not rendering correctly. Drongle has found a way to resolve the problem in mesh-prims. It has to do with the order of the polygons in the Collada DAE file.
You can read more about the problem in the SL Forum in Transparent textures on rigged mesh ‘bug-out’? There the discussion is mostly about the solution to getting hair ‘transparency’ to look right. Things like build order affect the appearance of the final product.
Drongle explains the things he found and how he tested build order and the order of polygons… well, triangles, in the Collada file.
Realize that in mesh the transparency problems are within a single ‘material’ in a single object. By applying different materials within the object the problem can be avoided. These must be materials each with their own UUID. So, they must use different material slots in Blender. Of course that drives up download time and lengthens rez time. But, the thing renders correctly.
Drongle was editing the DAE file. It is an XML file, which is a text file, so editing is not difficult. Knowing what to edit is a bit more trick. I’ve not tried it yet. Looking in the file, it is easy to find the geometry of the mesh. Knowing what to move around is a bit more complex.
Ashasekayi Ra tried reordering an existing build in Blender and had no luck fixing the problem. So, if one gets things out of order, there may be not fix other than to start over or edit the resulting Collada file.
The important question is whether the fix actually works and whether it works in all viewers. We as users will be able to determine that given some. But, will the Lindens do something that will change the render order? In other words will one of the in progress changes or some future change break this fix?
There is no answer to the question. Vir Linden is checking to find out if the Lab will consider the order of the triangles in Collada to be a feature of the Collada import render process and endeavor to avoid breaking it. I suppose that will depend on whether they think they can fix the transparentcy render problem.
ADITI Inventory Problems
I’ve written about this before. It is reported in JIRA SVC-7727. More and more people are getting caught by the problem. Unfortunately not everyone reads my blog… can you imagine?
We’ve asked Vir and Prep Linden to ask about getting it fixed. There is some assumption that there is a problem with the ADITI inventory server.
SL9B Challenge to Open Source
We have heard a bunch of people whine, cry, lament, and cheer in response to the SL9B announcement by the Lindens.
Oz Linden saw Tateru Nino’s blog post: So Now is Your Big Chance. In the mailing list for the Open Source group he offered a challenge to the Open Source Dev’s. Quoting Oz,
I love this blog entry from Tateru: http://dwellonit.taterunino.net/2012/04/18/so-nows-your-big-chance/ and am inspired to lay a similar challenge on our current open source community: If you’d like there to be an SL9B open source exhibit, and you’ll organize and execute it, I’ll provide the space.
Reference: opensource-dev Digest, Vol 27, Issue 27
One never knows what all the Lab is up to…
It seems most of the things on the radar are getting handled. Some items are moving slowly. But for the first time that I have noticed, the performance graphs show more fixes rolling out than problems coming in. You can see the graphs by visiting the JIRA and click the Projects item in the menu top menu at the bottom of the black area.
While I agree that things are moving in the right direction, LL have been undertaking a welcome ‘tidy-up’ of the JIRA (especially the VWR project it seems), closing and marking as resolved a number of old issues in the last month which has rather skewed the figures. I’m not being negative about this at all – I’m pleased to see this being done, as it helps all of us to be able to home in on what are the real problem areas.