#SL Mesh Deformer Update Week 48

In my #SL News on the 15th I reported I think the Mesh Deformer Project is setting off to the side. I mention that from Oz Linden’s perspective interest in the Deformer has died out. That drew some reaction in several places. Since a couple of days after the article things have picked up. I doubt I did all that. But, people are getting the word out.

Blender 2.64a – Transform/Rotation

I’ve also gotten several questions that surprised me. Some are pointing out they are new to this issue… which while that surprises me it shouldn’t. This project started a year ago and we have had a lot of people come in and leave during that period. So, I’m going to try to update things get people together.

If you find people confused on what testing is in progress and what needs to be done, please refer them here.

JIRA – Mesh Deformer STORM-1716

The JIRA is a touchy subject I’ll cover in another article. However, the Mesh Deformer Project lives in the JIRA as item: STORM-1716Mesh Deformer for tailoring mesh clothing. Fortunately it is a pre-JIRA-Change item so everyone can still read it. I think many of us can still post there.

About the end of October STORM-1716 went pretty quite. About the 17th of November conversation started up again. It seems the confusion was increasing as to which viewer and which test clothes could be used. I see this as another example of techies and artists not being able to communicate well.

Project Viewer Version

The structure of the mesh clothes data we upload has changed about 4 times now. Each time it has changed we have needed a new version of the Project Viewer. Unfortunately, several sites and forum posts have used the absolute URL for a specific version of the Project Viewer. Those URL’s do NOT update as the viewer updates. I think that has confused a number of people and created problems.

If you look in the left column of my blog you will see a link for the Mesh Deformer Project Viewer: SL Mesh Deformer. It leads to the SL Wiki’s page: Downloading test builds. That page has a dynamic link to the LATEST build/version of the Mesh Deformer Project Viewer. That URL looks like:

http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-2/arch/CYGWIN/quicklink.html

There are 3 links for Windows, Mac, and Linux. I am showing the one for Windows. The red part specifies it is Windows and the green part is the dynamic part. If you click it, for now you get linked directly to the download: Second_Life_3-4-1-266373_ProjectViewer-Deformer_Setup.exe. Each time the Project viewer updates this link automatically updates and sends you to a newer version.

There are a couple of problems with this process. One, it never appears to change and no version information appears on the SL Wiki page to indicate there has been a change. I am not surprised some people fail to realize anything has changed and keep using an older version.

Another is the use of quickly updating versions and static forum and JIRA posts. The version could be changing while you’re typing your post or JIRA comment. So, term LATEST VERSION is meaningless. Only a real version number like 3-4-1-266373 has any useful meaning. When people want to point or refer to a specific version of a viewer they use an absolute URL like:

http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-2/rev/266373/arch/CYGWIN/installer/Second_Life_3-4-1-266373_ProjectViewer-Deformer_Setup.exe

Again I am using the Windows specific link (red). Rather than posting 3 links, it is possible to post the build’s page:

http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-2/rev/266373/index.html

That link takes one to a page with links for Windows, Mac, and Linux. It also has the link to the release notes. But, it is NOT dynamic. The text ‘/266373/’ pulls the page for that build/version and ONLY that one.

People not familiar with how software is developed and how repositories work are unlikely to have any clue about dynamic links and rapidly changing versions. So, things have gotten a bit confusing as to which clothes were uploaded with which version and what version to use.

If the clothes maker did not include a viewer-used-to-upload version number with the clothes, we don’t know which viewer to use to test the clothes.

Since the data format for uploaded clothes has changed, no matter which version of the viewer you use, those versions of clothes are not going to work with any Mesh Deformer version. Regardless of version used, the Defomer code will just ignore them because the data currently being sent is adapted to the current format. Clothes uploaded with old version formats are converted the newer format for storage in the SL servers. The Lab does that conversion. But since the converted items are missing required information for the ‘newer’ Deformer they are set to NOT deform. They become ‘static’ rigged mesh. So, they will behave like clothes uploaded without the deformer flag set… like other items we do NOT want to deform.

To make all this simple, just figure that any mesh clothes set to deform and uploaded with a version other than the current Project Viewer (3-4-1-266373) are not going to work/deform. Assume any clothes you have not personally uploaded are too old to work. If this is not the case, expect someone to have put up a sign or provided a link that says which version they were uploaded with.

3DS Max

A problem with rigged mesh items coming from 3DS is they have not been working with the Deformer. They are rotated. This is a problem with how 3DS handles the XYZ axes. 3DS is a Y up oriented development system. Blender and Second Life use a Z axis up orientation.

The problem in the JIRA is explained by Darien Caldwell in a post:

3DS Max has serious Issus with the deformer. Because it’s axis system is turned 90 degrees from SL, deformation only occurs 90 degress from where it should. So if the mesh should deform out the front, it deforms out the side instead. There is NO KNOWN WORKAROUND at this time. I expect a custom Exporter will need to be written for 3ds to SL.

I don’t see this as a serious problem, but I’m not using 3DS. I am using Blender. Blender is rotated from most other 3D systems out there. So, I am used to adjusting what I build to other axis systems. In Blender we rotate the object then export it.

So, for an armature and mesh to work correctly coming from 3DS it has to be rotated in 3DS so it matches the SL axes. In SL X & Y axes are East~West and North~South. The Z axis is elevation, up. East and North are positive directions. This means in 3DS that the Z-axis’ positive direction must run from the avatars feet up through its head. The avatar’s nose must point in the positive X-axis direction.

There is a discussion of this same problem by those trying to get mesh into Unity. See: How to get the XYZ axis right.

Several of us that use Blender for Second Life do our building, weight painting, and animation with the avatar facing the Front View, Y-axis (press 1). Then prior to export we rotate everything to face the Right View, X-axis (press 3). While things face the Front View we can use X-axis mirroring, which makes the extra effort worth the trouble.

Kitsune Shan is pointing that out in a STROM-1716 comment.

Real Rotation

Another part of the rotation problem is: understanding when something is or is not rotated in the modeling tool.

In Blender if you model something so it faces the Front View then rotate 90 degrees on the Z-axis it turns to face the Right View. It certainly gives the appearance of having been rotated. But, it hasn’t ‘rotated’ it has been ‘transformed’. The mesh model still faces forward toward the Front View and has a transformation applied to make it LOOK like it faces right. There are reasons why this is so. Just take my word for the reasons part. It is fact that it is so.

If you open the Transform Panel (press N while in the 3D View) and look at rotations, you will see a 90 or -90 degree transform rotation on the Z-axis. To apply the rotation and ACTUALLY rotate the mesh object, not just transform it, press Ctrl-A and select Rotation. Blender applies the transform rotation to all the vertices thus actually rotating it. This ‘rotated’ object is then the item you export. This nuance of rotation in 3D modeling programs is often missed by new modelers. It got me several times.

I make all my avatars face right, looking down the X-axis. I then make sure to rotate them to face front using Ctrl-A and do my modeling and weighting. X-Mirror then works for vertices and weight painting. I then rotate them to face right, using Ctrl-A, and export them.

If a mesh clothing item comes in rotated wrong or not fitting correctly, it is likely you have messed up a rotation or missed converting a transform to a rotation.

WhiteRabbit made a tutorial and shared it in the JIRA comments. See: http://i.imgur.com/acPwE.jpg – Yes, it is a single image. It is made for 3DS.

Deformer

The mis-rotation of a mesh item can be hidden by the rigging. You may have seen an item mis-rotated appear for a second and then correct itself to align with the avatar. Apparently the problem is this mis-rotation throws off the Deformer. The fix is to get the rotation correct.

Delay

Some people are noticing a delay before they see the Deformer kick in. For a Quad Core anything that time should be in the 2 to 4 second range. But, busy computers or low end computers could see longer delays.

Very high polygon items can create 3 to 4 minute delays on slower computers. Consider. An item typically has 4 versions of itself. These are the LoD versions. These are supposed to have simplified polygon counts as the LoD changes. If a creator makes a high poly dress and uses the same mesh for all four LoD’s, that is a huge amount of data to be processed before the Deformer can start deforming. Thus the delay.

Some people have used high poly meshes (14k poly’s) and wondered if the Deformer was working at all. I suppose if they wait 5 minutes or so they make see it kick in. The avatar is about 7,000 poly’s.

Multi-Threaded

Darien Caldwell seems to understand the viewer code for the deformer and how it is set up.  Darien says that each mesh calc runs in its own thread. Darien says 5 people should calculate simultaneously.  I’m not sure why Darien says 5…

Whatever, slow computers are going to take longer to start rendering deformed mesh. Poly count is going to be very important for mesh clothes that are designed to use the Deformer.

Test Clothes

Submitting test clothes is something I’ve written about a number of times. These are needed by the Lab to confirm the Deformer is working as we, the user community, and they, the Lindens, think it should. I imagine the Lindens won’t be hard to satisfy. If the user community says these are my test clothes and there is a problem here and there, a decision will be made if the problem has to fixed or can be lived with and the project can move forward.

Test clothes need to be UPLOADED with the Latest Project Viewer, now: 3-4-1-266373_ProjectViewer-Deformer. That could change at any time for any number of reasons, several of which would not be related to the Deformer.

The instructions for submitting test clothes are in STORM-1716 here. Oz also posted a copy with more details in the SL Forum here: Mesh Garments needed for testing deformer.

The clothes were to be available via Oz here: Hippo Hollow. I’ll try to remember to ask Oz if the old clothes have been taken out of the closet.

Alternative

Some people have a silly fear of the Contribution Agreement. If one does not understand a legal document they should not sign it. So, as silly as I think it is not to sign, don’t sign it if you don’t understand it. There is another way to contribute.

Put the clothes in the Market Place for L$0. Provide a link to the item(s) to Oz Linden and may be put it in JIRA STORM-1716. BE SURE YOU INCLUDE THE VERSION of the viewer you use to upload the item.

Also make sure you provide all the other information asked for in Oz’s requests for test clothes.

2 thoughts on “#SL Mesh Deformer Update Week 48

  1. Thanks for making the things a bit more simple for everyone.

    But I would like to clarify something. The workaround that WhiteRabitt0 is pretty good, but only works to fix explicit issues. He/she had to make a new skeleton and paste the weight data which means that on the process of skinning the mesh he/she messed something on the skeleton that made that error. As you point, the problem is just to make the model to face +X (local axis) and export with Zup. This isnt just on 3DS Max is also in Blender and all others app. So even if that little guide is really nice for those who cant fix the mesh deforming properly after facing to +X, they may also understant that this isnt a final fix and they can run into the same problem where this fix may not work properly.

    Regards.-

Leave a Reply

Your email address will not be published. Required fields are marked *