Tag: Mesh Deformer

SL projects update, September 26th

Posted on by Inara Pey
Update 28th September: Please also refer to an update post on some of the projects / news given here.

SL Viewer Status Updates

Linden Lab have been working hard on a range of viewer-related issues, notably crash rates and memory leaks, which have slowed the viewer update a release process up over the last few weeks. In terms of memory leaks, tcmalloc has been identified as the culprit, with Linden Lab deciding that dropping it is “probably a good idea”, according to Oz (tcmalloc has previously been implicated in crashes linked to the use of things like Microsoft’s Skydrive). There have also been an issues with LL’s statistics system which have meant that the viewer hasn’t necessarily been accurately tracked in terms of crash rates, etc.

Beta Releases

As it stands, LL hope to have the blocks on the various code merges removed during this week, which should see a rapid series of beta releases coming down the pipe. This work commenced with an initial 3.4.1 beta release (3.4.1.265134) emerging on September 24th. It will be followed by around three or so additional and rapid 3.4.1 build iterations aimed at confirming the viewer’s stability and at replacing various fixes which had previously been removed from the viewer code while trying to identify the causes for the viewer crashing / suffering memory leaks. It is expected that each of these iterations will be on the beta release build channel for a couple of days, prior to being replaced. Following these there will be a series of project updates, the first of which gatekeeper compliance project, which is also targeted for a 3.4.1 release build.

Project-related Releases

Once the stability of the beta viewer has been confirmed, it is anticipated that project-related code will be merged into the viewer, most likely starting with 3.4.2 builds. Among the releases planned for 3.4.2 is Monty Linden’s HTTP Library Services and Baker Linden’s Group Services code. These are currently targeted to reach the beta build channel in week 40 (week commencing Monday October 5th).

These releases will at some point include the Steam updates currently in a Development branch as well, which might in turn mean that Second Life could be ready to appear on Steam in the very near future, once these updates have reached a release version of the viewer.

Account creation prompt: heading for the beta viewer

Group Services Project

The Group Services project is an attempt to improve the management and editing of large SL groups by replacing the current UDP-based service (which has capacity issues with the size of group lists it can comfortably handle) with a new HTTP-based service. The project viewer for this is already available (for Windows, Linux and OSX.), however, as mentioned above, the current plan is to get this into the 3.4.2 build stream alongside the HTTP textures project, possibly in week 40.

Originally, the server code for this project was due to have been rolled to the RC channels during week 38, (week commencing September 17th), but the channel deploys were postponed after QA issues were found. As a consequence, the roll-out was due to take place on Wednesday 26th September, but has again been postponed.

There has been some confusion as to the aim of this project, with some people believing it is focused on fixing group chat issues such as  lag and chat failing to start. This is not the case at all; as stated above, the project is aimed at improving the management and editing of large groups (10K+) through the use of a new HTTP service.

HTTP Library Services

As indicated above, the first phase of this work, covering a new texture fetch service, should be appearing in a 3.4.2 beta release of the viewer in the near future.

HTTP Libraries project viewer: improved texture loading and rezzing

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

Pages: 1 2

Upcoming SL projects update

Posted on by Inara Pey

There is a lot going on in terms of projects and development work in Second Life. The following is a further update on a number of key projects I’ve been following and reporting upon through the pages of this blog.

Group Services Project

The Group Services project is an attempt to improve the management and editing of large SL groups by replacing the current UDP-based service (which has capacity issues with the size of group lists it can comfortably handle) with a new HTTP-based service. The project viewer for this is already available (for Windows, Linux and OSX.), as I reported last week.

This week sees the server-side code rolled-out to all three RC channels (Magnum, LeTigre and BlueSteel), allowing the project viewer to be tested in handling very large groups (significantly larger than are available on Aditi). Note that those running viewers without the new code on any RC region will be unaffected, as they will continue to access the current UDP service.

There are still no timescales as to how long the testing of the service will last (“It’ll take as long as it takes,” Baker commented recently), or when the viewer code will progress beyond the project viewer. However, a number of things should be noted in reference to the eventual roll-out:

  • The viewer code is not being made back-compatible with V1 code by the Lab. Therefore, TPV developers using the V1 code base will have to backport the code themselves in order to use the new service
  • The initial HTTP service roll-out does not include any data compression. This means there will still be some delay in downloading member lists for very large groups with tens of thousands of members
  • Once the new service is rolled-out, which service is used is entirely transparent to the user. If a viewer with the new code is running on a region which has the server-side HTTP service, it will connect to that service. If it is on a region using the older UDP service, it will connect to that service instead
  • Once the HTTP service is fully deployed, viewers which do not implement the viewer-side code will still be able to access groups with member lists up to 10K in size via the UDP service until such time as it is switched off (which will not occur for some time after the HTTP service has been rolled-out). However, attempts to access groups with lists larger than 10K will fail.

Interest Lists and Object Caching

It’s been a while since I’ve reported on Interest Lists Object Caching, which forms a part of the Shining Project.

To recap: when you enter a region at the moment, your viewer receives a huge amount of information on what requires updating, much of it relating to things you can’t even see from your position in the region. This information is received in no particular order, with the familiar result that things appear to rez in your view in a totally random order. Not only that, but the chances are that if you’ve previously visited the region, much of the information being sent to your viewer is already locally cached – but is being ignored. The focus of this project is to both optimise the data being sent to the viewer and the information already cached on the viewer with the aim of significantly improving object rezzing times in terms of speed and order (so objects closer to you rez before those further away, for examples).

Object caching and interest list changes: easing the pain of random rezzing

Andrew Linden had hoped the project would be going to QA this week ready for roll-out to one or more RC channels in the near future, but some last-minute problems popped-up and have delayed things until he can get them sorted out. In the meantime, the code has been deployed to a number of regions on Aditi, and Andrew plans to, “Try to throw a pile of test avatars at it to stress it out. Later this week.” No viewer-side changes are associated with this work.

Materials Processing

Work continues on the project to bring materials processing to Second Life. Last week, it appeared as if the new materials – normal and specular maps – would have their own rotation and positioning options independent of any texture (diffuse) map. This week, it appears that this is the hoped for situation, but the matter is still open to question – which goes to show how fluid the project is.

The new capabilities require changes to the rendering pipeline, and details have been released on some of what this entails.

In order to work, normal and specular maps require what is referred to as per-pixel lighting (as noted in the original blog post on the subject). As such, there has been a debate on whether it would be better to develop a per-pixel lighting framework within the viewer, or work to make the current deferred rendering system more accessible to per-pixel lighting capabilities. As the latter approach will allow getting materials processing working within SL sooner than would otherwise be the case, it has been decided to go that route. Thus work is focused on making the current lighting system more configurable and able to better handle a broad range of material types (metallic, matte, plastic, etc.), together with adding support for both per-object and per material shading differences.

However, a dedicated per-pixel lighting framework does offer advantages of its own, and as such is being considered as a possible future extension to the project, which may be implemented at some point down the road. One such advantage is that could potentially be run in a non-deferred mode, which might lightening the load on older graphics systems.

Please use the page numbers below to continue reading

Pages: 1 2

Recent SL viewer activities

Posted on by Inara Pey

It’s been a while since I’ve reviewed any of the official SL viewers from LL, so here’s a quick round-up of recent releases.

New Log-in / Account Creation Prompt

The new account creation prompt, displayed if the viewer does not locate any user settings files on a computer, and which first appeared in the 3.4.1.263582 release (August 16th), now looks to be the default option for all development / project viewers. It is part of both the most recent Mesh Deformer project viewer (3.4.1.264215, August 31st), and the new HTTP Group Services project viewer (3.4.1.264495, September 7th). However, it has yet to filter through to either the Beta or release versions of the Viewer.

Account creation prompt: now standard on all development / project releases of the SL viewer released since August 16th (click to enlarge)

Mesh Deformer Project

August 31st saw a new release of the Mesh Deformer (3.4.1.264215), which includes a revised mesh uploader floater with deformation options for the male and female shape.

New deformation options

According to Nalates Urriah, the new options invalidate all test items so far provided for the project, and new samples are now required, although no comments to this effect appear to have been made on the JIRA or elsewhere, so they may have been confined to a user group meeting. Details on how to provide test items can be found in Oz’s forum post on the matter. The JIRA (STORM-1716) for this project is still open for viewing and comment.

Group Services Project Viewer

As noted this week, there is now a Group Services (group management) project viewer available for testing the new HTTP group management service. The server-side of this project has yet to be rolled-out to Aditi, so it cannot be tested as yet. However, Baker Linden, who is developing the service, is apparently updating the JIRA, SVC-4968 (which is still publicly viewable) with the project status, and has indicated he’ll post when the server-side elements are available for testing.

The viewer is available in Windows, Linux and OSX flavours.

HTTP Libraries Viewer

The HTTP Libraries project viewer (3.3.3.262585) appeared on July 27th. This project, which Monty Linden is driving, is currently aimed at improving texture downloading and rezzing as a part of the Shining project.

HTTP Libraries project viewer: improved texture loading and rezzing

Texture loading / rezzing would appear to be significantly faster on this viewer compared with other offerings, although there also appear to be what might be placebo effects associated with it. Some people have reported that floaters, etc., seem to load more slowly, and some have reported various performance improvements outside of the HTTP library changes.

Beta Viewer and Release Viewers

The Beta viewer (3.4.0.264445 at the time of writing) continues to be focused on pathfinding, with fixes and updates going into it on a weekly basis – which is why the pathfinding tools have yet to release a release version of the viewer.  The removal of JIRA numbers from the release notes now means that tracking issues previously being watched is that much harder (even if the JIRA themselves are no longer accessible, having the JIRA numbers still visible facilities easier identification of issues being specifically tracked).

Similarly, the release viewer (3.3.4.264214) appears to be focused on bug fixes and general improvements, with the release notes currently benefiting from the retention of JIRA numbers, making scanning for specific fixes easier.

Performance

I carried out basic performance tests on the viewers listed above using Dimrill Dale as my sample sim, during a period when there were the same number of avatars in the region (5, including myself). Tests were carried out in the same location on the region, looking in the same direction and with the same viewer settings (e.g. Graphics on high, Draw Distance set to 260m, using default time-of-day, with deferred disabled / with deferred enabled and lighting set to Sun/Moon+projectors, etc.). While all such tests are rough-and-ready, these did tend to show that all of the viewers offer the same performance on my default PC (see the sidebar panel on the right of this blog’s home page for system details). My results were:

  • Non-deferred: 18-20fps
  • Deferred with Sun/Moon+ projectors: 8-10fps

Similar figures were also obtained using the current Firestorm and Exodus viewers, although with deferred enabled and Sun/Moon+projectors active, Firestorm was slightly down at an average of 17-18fps, the other viewers being closer to an average of 19-20fps.

Mesh content creation: morph targets proposal

Posted on by Inara Pey

The Content Creation Improvement Informal User Group has started work on putting together an exploratory proposal for consideration by Linden Lab on the subject of morph targets.

Morph targets (also known as shape targets, per-vertex animation, blend shapes, shape interpolation in some 3D applications) are generally used for complex animations that would otherwise be hard to accomplish with skeletal animation – such as facial animation and avatar customisation. In this latter respect, the SL viewer already uses morph targets to a degree.  The proposal being drafted is aimed at the implementation of a more widespread use of morph targets, for use in such areas as:

  • Complex facial animations on rigged meshes
  • Additional ways for a user to customize the appearance of their avatar
  • Animating the surface of a prim without the need to use a custom skeleton
  • Fine grained control for content creators over how their clothing and avatars deform
Morph targets: animating facial features

It is with regards to this last bullet-point that morph targets are particularly interesting to content creators, as they are seen to have significant potential advantages for clothing deformation than might otherwise be offered by either the parametric deformer, or RedPoly’s alternative approach.

The proposal outlines some of the drawbacks in the latter two approaches, and covers some of the advantages and issues in adopting morph targets. One advantage in using morph targets is that they would allow a content creator to “sculpt” how a morph target should appear, directly within their 3D application of choice, thus giving them the ability to directly control over how a mesh deforms around an avatar (or how a rigged mesh replacement avatar deforms around the base avatar). A potential issue with the approach is that morph targets require additional information to be encoded either within a mesh, or within a texture. This means that additional bandwidth will be required to transmit any mesh which uses morph targets.

Morph targets: a better means of getting mesh clothing to deform?

As it stands, the proposal is in its early phase, although the intention is to complete it and submit it to LL for consideration and feedback as soon as it is felt enough information has been put together. Geenz Spad, co-chair of the CCIIUG, is aware that at the moment, much more input is required in order to get to that stage.

“There could be more input with regards to the content creator’s and the technical perspectives,” he commented to me in discussing the proposal, “The biggest bottleneck is just getting enough input to finish the proposal at this stage.” Of the two perspectives, Geenz feels that it is the technical side of things that is perhaps the more lacking of the two and he would like to see more input from those of a technical mind in terms of potential feature implementation, advantages, disadvantages, possible issues, and so on.

If you are in a position to provide input to the proposal itself, your views would be most welcome, as would your presence at the weekly CCIIUG meetings, which take place every Tuesday, from 15:00SLT at the Hippotropolis Auditorium.

Related Links

Mesh clothing deformation: options

Posted on by Inara Pey

The informal content creation user group is into its 2nd week of meetings. I attended the first, but frequent Viewer crashes meant I lost a huge amount of context during the meeting (particularly as a non-specialist), and didn’t feel entirely comfortable providing a write-up based entirely on the transcript of the meeting. I also missed this week’s meeting due to working on other things.

However, Nalates Urriah provides an overview of the meeting and the core discussion on mesh clothing deformation, which I’m using, together with the meeting transcript, to provide a summary here.

As most people are aware two deformation options have been put forward: the parametric deformer first proposed by Max Graf and which Qarl Fizz has been developing (and versions of which have been made available through an SL Project Viewer), and recently the option presented by RedPoly Inventor.


An early video from Qarl on the parametric deformer

For content creators, both options have certain advantages and disadvantages, and opinion on both has been somewhat split. Of the two, however, the parametric deformer is furthest along in development and potentially offers the more direct means for creators to ensure mesh clothing fits. While RedPoly Inventor’s system offers the advantage of appearing to work with the existing shape sliders, in its current form it will be reliant on alpha layers to a far greater extent, adds complications to the process of weight painting mesh, and would likely require the development of a new set of avatar bones in order to fully work and meet consumer’s expectations.

During this week’s meeting, discussions continued around another “alternative”, that of using morph targets – a special shape that defines how a mesh should deform when a certain parameter is increased or decreased. Morph targets are widely used in 3D modelling and are in fact already employed in Second Life to some extent: they are activated when using the existing appearance sliders, However, in order for them to work in terms of mesh clothing, etc., would require updates to both the viewer and on the server-side and would be dependent upon additional data handling – so further support from Linden Lab would be required in order for this option to mature.

However, it does offer advantages:

  • It is theoretically far more flexible than either the parametric deformer or RedPoly’s proposal
  • It would leave content creators entirely in control as to how a mesh deforms
  • It would probably offer faster rendering than Qarl’s deformer
  • Morph targets might be used for animating mesh avatar facial features

For those interested in the more technical discussion on morph targets and SL, the transcript of the meeting is the place to visit, covering as it does such diverse aspects as LSL support for the approach, working with avatar physics and so on. In particular, there is detailed discussion on what needs to be put into any proposal relating to the use of morph targets that could be put to LL – a discussion liable to continue in next week’s meeting.

As Nalates points out in her article, there was also discussion on how to move things forward vis-a-vis Qarl’s deformer – Qarl has previously indicated via Metareality that he is more-or-less waiting for a consensus from “the community” (although it is doubtful any consensus can be reached without LL having a cast of the dice). This also involved debate as to whether things have to be an either / or solution, or whether things could move forward on more than one front.

To this end, Nalates has set-up a poll on her blog. If you understand all of the issues involved on the situation, and have a clear opinion on what you would like to see, please take a minute to complete the poll.

Metareality discusses the “RedPoly” approach to mesh deformation

Posted on by Inara Pey

Note this is a 2-page article. Use the page numbers at the end of the piece to page back and forth.

Today’s Metareality podcast covers, as usual, a lot of topics, including Cloud Party and, more particularly the possible alternative approach to mesh deformation as proposed (or possibly re-proposed, given LL apparently looked at the same idea last year) by RedPoly, and which I covered in an earlier report this week.

The panel for this panel for this week’s show comprised Kimberly Winnington, aka Gianna Borgnine in-world and Karl Stiefvater, Qarl Fizz in-world, who were joined by Cyclic Gearz  and Geenz Spad.

While you can hear the broadcast in full over at Metareality, here’s a transcript of the discussion around the alternative means of mesh deformation.

[02:47] Gianna Borgnine (GB): So what is this new deformer, and how is it different? … For what I understand it works on bone definitions, is that right?

Geenz Spad

[03:07] Geenz Spad (GS): Well, basically yes, it uses several unused bones in the avatar skeleton … I guessing were used at some point to calculate the bounding box of the avatar on the server for collisions or similar. So, that’s mostly what it seems to be right now.

[03:30] Qarl Fizz (QF): I can probably add some more, but I should also specify that this is complete speculation because I haven’t had a chance to dig in … It seems like, yes, for the purposes of physics and maybe other stuff, at one point the Lindens had this approximation system put in so that when you dial your avatar sliders around, they have a basic gist of what your avatar looks like. And someone came up with the idea of using this information to do the deformation instead of the actual morphs themselves.

[04:10] GB: So, Cyclic, maybe you could answer this best: what about this is so appealing to the content creators?

[04:15] Cyclic Gearz (CG): Well, from my perspective, well, I make furniture mostly, but I still know a lot about design and stuff …  And all my designer-friends who make clothes … and part of the most difficult and annoying process is having to make five separate sizes currently, because at the moment that’s the best option for attracting the most customers – having more sizes that fit more bodies – if they have a deformer that works as is, and they do the work outside of Second Life, it reduces the workflow, it reduces the time to make new things; [it] means that they can get more stuff out and therefore more customers are happy.

[04:55] GB: So my guess is, I mean I talked to a few different people and got a few different opinions, and it was interesting to see the different sides and probably the only person I talked to … who wasn’t as thrilled about it, other than some of the developers I talked to, was Maxwell Graf, who is always looking to get rid of extra sizes, so I thought he would be excited! But for him, one of the big things was that it still felt like so much extra work because now he’s back to weight painting, which is something he was trying to get away from with Qarl’s deformer … But the thing that, as a person who does not make mesh fashions … Right now at least, you’re sort-of weight painting, but you’re painting blind, because you have to upload it to see the effects of what you did. Is that right?

Avastar in use

[06:06] CG: Sometimes; it depends on how you make your mesh. For instance, with blender you can get a plugin which you can pay for called Avastar by Gaia Clary. That is a really good way of seeing what your weight painting does and has an affect. You can also get a free burn file for Blender which is called The Avatar Workbench, also from Gaia Clary, where it has got all the bones and stuff and you can see what it’s supposed to look like. But you do sort-of have to guess … if you’re not versed in mesh or anything like that, and weight painting at all, it can be quite daunting. So from that perspective, not having to weight paint would be better for newer creator, because they’d be able to build something in blender or a different commercial program and not have to weight painting, because that is really horrible stuff! But … I do think people need to learn these skills, because the skill you learn for making 3D in Second Life can be applied in real life for big jobs … you could go into the games industry making models and stuff; but if you can’t weight paint, you’re out of luck!

[07:22] GS: Personally, I used to be an artist before I was programmer, and 3D animation was something I was always very interested in, and I definitely know the pains of having to go through and paint a variety of different vertex weights for different bones and things like that. And one thing that seemed interesting to me to the new approach to a deformer that works across all viewers that support mesh is that … you have 20-something bones you currently have to rig if you really want something that really looks good and really deforms well on most avatars with regards to just an avatar moving around; now you have all these additional bones you now have to worry about. That really seems to be the biggest drawback here. Granted, there are ways to mitigate this, and as I was saying on Monday, someone should find a better workload for this if it’s really going to be a viable solution.

[08:19] GB: Which made you really unpopular…!

[08:23] GS:  (Wryly) yes, because I’m a terrible person for suggesting something rational here, I guess!

[08:49] QF: So, I don’t know actually how this works, so may be you can help me, Geenz. So, what I said is true, right? These are like pseudo joints that the visual params modify to kinda …

[09:09] GS: … Kind-of get an idea of how big the collision capsule server-side should be – that’s what I’m guessing, you know? I could be wrong.

[09:12] QF: but you can’t visualise these in Blender at all, can you?

[09:18] GS: You pretty much have to manually add them currently.

[09:20] QF: So there’s no good way to … like Cyclic was saying, painting weights is hard, but you’re painting weights for … totally blind, right?

[09:33] GS: The worst part is here … there’s no guarantee that these will actually stick around in future versions of Second Life. I mean for all we know, after RedPoly outing it, Linden Lab may remove it in X number of months or they may keep it just because they’re afraid people began making content – and we know linden Lab’s policy on content breakage – So its either they’re going to break it now, or they’re not going to break it because people are going to make content with it. Danger of content breakage, here we go!

[10:10] GB: Well, Linden Lab is going to have to weigh-in at some point, because as it stands right now, it doesn’t deform around breasts or saddlebags or anything, so they would have to add in order to make it work right, right?

[10:23] GS: And on top of that, from what I can tell, the skeleton that’s being used is mostly just a rough approximation of the avatar itself in terms of its shape. That’s all you’re really going to need if you’re going to calculate a bounding box or a bounding capsule or something like that.

Continue reading “Metareality discusses the “RedPoly” approach to mesh deformation” →