Good meeting on mesh problems this week and the state of SL Viewers. For 3 or 4 months we have been having problems with the SL Viewers. Runitai Linden is working with many of the viewer’s OpenGL issues affecting us. These problems extend into third party viewers using the V3 render pipeline from the Lab. So, what can we expect?
Viewer Fixes Lagging Behind
Those of us that use project viewers and the development viewer know that many of the problems in the main SL Viewer and SL Beta Viewer have been solved. But, those fixes from the project and dev viewers are slow reaching the main viewer. Plus these viewers have had problems most residents would not want to put up with.
There are, what I consider, two primary hold ups delaying fixes moving to the main viewer. First is the chaos of rapid development. Multiple teams are tackling various aspects of the viewer. That makes for quicker fixes, but adds the problem of integrating and testing the fixes. More people and teams mean more work is done but communication problems increase. This means we see fixes in project viewers that take time to reach the development viewer which precedes the SL Beta Viewer which precedes the main viewer.
Another problem is the Mac/Windows versions. The Lab seems to have a short leash between the Mac and Windows versions of SL. I see this less as an intentional leash than a complexity of testing fixes and maintaining quality… or stability. A fix needs to work for all platforms. It seems any given fix is kept separate from other fixes so it can be more easily tested. Once working well in all platforms it moves into integration with other fixes. The goal is to fix as fast and efficiently as possible. But, the road to a well working viewer is long.
Getting something working for Windows and pushing it into integration with other fixes is faster. But, if a fix for the Mac changes the idea of what works or is a good solution, then the Windows version has to change and a considerable part of the work has to be done over. The Lab thinks they have the best balance of development, testing, and delivery. We don’t know enough to know whether they do or don’t.
Waiting is always annoying. I guess we learn to deal with it.
OpenGL Fix
Not really a mesh topic, but important to all. See: #SL OpenGL Fixes
Odd Land Impact Costs
An oddity has been found in some mesh models having less Land Impact cost when more textures are added. As best we can tell that is backwards and likely a bug. The Lindens are looking at what is going on.
Dustty asked about the confusing LI on his mesh object in a forum thread titled, Prims Land Impact Whatever. Drongle McMahon has done some testing to figure out what is happening. (post reply)
Once the Lindens have had some time to look at the information and the Collada files they will post a response in the thread.
Odd LoD Breaks
An LoD break is the point at which your viewer changes from showing LoD Highest (#1) to LoD High (#2). There is an equation that controls where the viewer makes these changes. It is based on the object being viewed.
Kwakelde Kwak reported the anomaly in the forum.
Understanding where the LoD breaks occur is important for those designing low Land Impact objects that keep their shape as one moves away from and toward them.
Drongle McMahon explains the base consideration for determining the objects LoD break points is based on half the objects bounding box diagonal which is then used as a spherical radius. (radius = sqrt(x*x + y*y + z*z)/2) – that is a simplified equation for better viewer performance.) The bounding box diagonal can be minimized by aligning a long dimension along a single axis.
The bounding box radius does have an effect on Land Impact cost and LoD break points.
Kwakelde tried rotating an object so the long dimension was in Y rather than Z. The change moved the LoD break points farther out. If this worked it would allow one to use a more simplified model for LoD High (#2) and gain a reduced Land Impact. But, Drongle could not reproduce the effect. Nor could LindaB Helendale when she tried simple meshes of different shapes. (post)
So, it does not make a difference whether the long dimension is along the X, Y, or Z. It does matter that the long dimension is along one of them.
One minimizes or maximizes the size of the bounding boxes volume depending n what they want to accomplish. As best I understand a minimum sized bounding box produces the best results.
Mesh Deformer Update
There is no new news on Mesh Deformation. All Charlar Linden was willing to say is they have completed the research into options for the feature. One can infer from Charlar’s wording they are getting closer. All he will say is they are not yet ready to talk about it.
Maxwell’s project is fully funded. I have not heard anything out of Maxwell or Qarl.
By the way… the Mesh Deformer project is funded and closed (Thx Inara, for correction). And if you have not donated toKirsten’s Viewer project, please do. I think both are worthy causes and worth our money.
Mesh Project Viewer
The Mesh Project Viewer is not updating often. In response to a question about that there were several responses.
Vir Linden: “We will probably be discontinuing mesh project viewers once we get the last batch of work merged down. That doesn’t mean there will be no future work on mesh, just that it’s not our current area of focus.
Runitai Linden: “Moreover — mesh is now a core component of SL, so fixes for mesh issues will go into the same branches as other fixes.”
Neck and Center Attachment Points
This is an interesting change. One can follow the developments and vote (by WATCHING) the feature change in JIRA STORM-1672 – As an Avatar/Vehicle/Jewelry designer, I want access to the Neck and Root attachment point menu options.
You’ll find this feature already active in the Dolphin 3 Viewer’s latest release.
Nyx Linden said in response to my ‘when’ question, “So it’s on its way along the normal pipeline of work 🙂”
Reporting Mesh and Viewer Issues
One of the problems in reporting bugs and making feature requests is knowing which project to place them in. Nyx Linden says, “VWR is a general bucket, STORM is for fixes specific to the snowstorm team – which handles opensource contributions, small bugfixes, etc. The distinction is mainly for us to keep track of which team owns the issue.”
Summing It Up
Fewer and fewer mesh issues are being discussed as mesh stabilizes and users learn more about how to work with it. It is nice that the Lindens are answering a wider range of questions. The group is a content creation group, so that is understandable.
The forums are proving to be a rich source of mesh news and education.
Nalates,
Just an FYI regarding the Parametric deformer. 🙂
Maxwell has requested that people DO NOT donate further funds to this project. The required total has been reached in order to code the initial single-layer solution, and he and Qarl have agreed that any additional features will be the subject of a future project, which in turn will have it own *separate* funding page.
You can see Maxwell’s comments both on the the comments section of the Indiegogo project page and in my interview with him from last week.
Inara
Thanks for the correction. 🙂