Pivot Points

Oh, surprise, surprise! Pivot points came up again. To which Nyx Linden said, “We don’t currently have this work scheduled, but I’ll make a note that it’s still a high priority for our creators.” Well… that is better than a flat ‘no plans to implement.’

Projects in Progress

I and others often ask Lindens if they have anything new to talk about. Nyx says we can find out everything we want to know, if we just get a job at the Lab… of course they’ll have you sign a Non-Disclosure Agreement to effectively block you from telling what you have learned. :/

No Comment

Crash on Mesh Upload

We are finding more people trying to use Microsoft’s Skydrive and experiencing viewer crashes whenever any file manipulation or access via a file dialog is attempted. See:

VWR-28843 – Microsoft Skydrive: Viewer crash on any file browser operation.

This was run into by one of the people working with mesh in the user group. Latif figured out a fix and put it in the JIRA item.

Deformer Glitches

I haven’t tried the new 0.3.3 Deformer. It’s in the new Linden Deformer Project Viewer. I’m not sure which version is in which TPV’s. But, some are seeing mesh clothes appear and disappear. I saw that with the 0.2 Deformer in Niran’s viewer. As best I could tell the Deformer was skipping frames, more than one. Since the output wasn’t ready for the render pipeline it did not get rendered. I’m guessing. It seems the same thing is happening with 0.3.3 Deformer. I expect this to get fixed. Once Qarl has a solid implementation then it is time for optimizing.

Prim Saving Mesh

There are some peculiarities being found with how one implements a mesh object in Second Life®. One of the mesh builders found that including the physics layer with the mesh upload consistently created a higher prim cost for Land Impact than separate uploads. They found that if they uploaded the physics model separately and then linked it to the mesh object, the separate upload process reduced the final prim count by 35%. That is significant.

Today the builder was asking if this is a bug, likely to be fixed or were things working as intended. Nyx is examining the model to see.

Invisible Small Objects

The idea came up about having small objects, like say a hair brush, completely vanish at the lowest LoD. The smallest LoD level for many small objects is a single triangle. The complaint I heard is that the triangles are ugly. There is an idea that they should completely disappear. The triangle should not show.

I think there are numerous ways to hide the triangle so it is invisible. So, I didn’t understand the need for a change in how the lowest level LoD behaves.  It think many will NOT want larger objects to disappear at the lowest LoD, like a castle in the distance.

Vivienne Daguerre explained what she found, “I have rezzed two arches, using both the same low poly Collada file and the same lower poly physics shape Collada file. On the first one, the 55 prim one, I uploaded in the normal way, attaching the physics file on the uploader. On the second one, the 36 prim one with Ivy, I uploaded the low poly Collada file first with no physics shape. Then I uploaded the same physics shape Collada file separately, made it transparent and linked it with the low poly Collada file. I then set the physics shape to be “prim” and the other to be “none”. I can walk through both arches, and the detail and LODs are the same, but one is significantly lower prim. Does this represent some problem in how land impact is being calculated on physical meshes? Does it suggest a desired method to have lower prim physical mesh?”

I am hoping this is an intended behavior. Nyx is working on an answer.

Triangle Order

Surely everyone knows about the problems of transparent textures and mesh. The render order and Z-axis sorting are problems in all 3D worlds, including SL. A work-around was found for SL. It has to do with reordering the vertex list in the Collada file before upload. That seems to provide an ordering that works for better Z-axis sorting.

Vir Linden today pointed out that reordering the vertices in the Collada file would not be a reliable work-around.

Drongle McMahon asked: “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?”

Vir Linden responded, “I have an answer from davep [Runitai Linden]: The rendering order can and does change and is effectively undefined. Specifically, the rendering order is changed to maximize vertex cache efficiency. The method used to cache-optimize triangle order might change. See the code: repository link.”

“So sorry, don’t count on that behavior.” Says Vir.

Summary

Lots of good information in today’s meeting. If you have creative relative questions get them in the agenda.