Prep Linden

Kyo Hellmann wrote: Hey, I'm having trouble uploading mesh models with skin weights. (I will try to be as descriptive as possible. I have all the bones, I've got skin weights, and I export them with the 2010 fbx collada exporter, but when I try to check the "Include Skin Weights" box, it's grayed out! I'm using the Wiz Daxter SLAV for 3ds max, and I use 3ds max version 2010. I add a skin wrap modifier to the torso, and add the head and lower body to that skin wrap. Then I attach the three editable meshes, convert the skin wrap to a skin, and do some touch-up on the weights. I don't usually do "Export selected", but I have tried, and it STILL won't work. If somebody could help me out, or just right out all (and I mean ALL, because I must be missing something.) the steps, it would be greatly appreciated. There are a number of warnings and errors that are surfaced before the skin weights option is disabled, gaia mentioned some things here ( http://community.secondlife.com/t5/Mesh/Specifications-for-SL-Compatible-DAE-Format/td-p/1343257 ), but in general if you could look or post your second life log, we could tell you where it's failing. -prep

Bloodsong Termagant wrote: heyas; is there (or can there be created, please) information on the specific DAE formatting that SL expects to read on import of a rigged mesh? i keep generating dae files where sl does not recognize it as having a rig, and i have no idea why. and/or why my dae files have different sections and codes than racush's simplebot.dae that is the only one that seems to work for me. the closest i found was this: http://wiki.secondlife.com/wiki/Mesh/Mesh_Asset_Format but it appears to be the format of the mesh file AFTER the sl importer parses it. i need to know this information, but what it expects in the DAE. oh, and this: http://wiki.secondlife.com/wiki/Mesh/Troubleshooting but it just says 'collada 1.4' which is not helpful. i need an analysis of what blocks need to be in the dae and how they need to be formatted. thanks! Ahh.. So many things could possibly be contributing to a rigging issue, did you enable the "skin weights"? and did you see the mesh go from a tpose into an idle stance? Could you post some information from your second life log - specifically the area beginning with "Collada Importer Version:" and following. It probably contains some information on what specific aspect of the import or parsing process failed. Best, prep

Ashasekayi Ra wrote: So, a new official release for Blender is out: Blender 2.6. It still works for making static mesh. But now, it exports a rigged mesh that is incompatible with the SL uploader. So, if you are making rigged mesh, you'll probably want to stick with Blender 2.59. Asha: Email me the rig that Blender 2.6 exported (prep@lindenlab.com)- I'll take a look at it. I imagine it's a minor issue. -prep

Heb Dexler wrote: Hi Prep, I missed the followup where you say " mimic the joint hierachy, rename the nodes..." To spell it out for a dummy, Do you want us to copy the joint positions from the main skeleton exactly or use the collision joints positions from the xml file? (which appear to be offsets from the skeleton bones) . Skin with just the collisons bones or both hierachies together? Here is 3ds Max script to make the skeleton, collison bones as copies or using the xml positions. Skeleton.ms - CollisionBones.ms - CollisionBonesXML.ms Rigging to the collision volumes can work! During the beta, untill diabled, it was possible to resize and positon a worn mesh using custom sliders. Here's my post from the old forum and Here's a video of the results. Heb: Thanks for the sample assets - could I also get the sample boot from you (I'm assuming that it's rigged to the collision volumes)? because that affect is exactly what I want to achieve except with out the use of the custom sliders. I'm thinking that asset would be easier to iterate on rather than an entire mesh rigged to the collision volumes. -prep p.s. replied to you directly w/more details!

Wonderful! Thank you! Ashasekayi Ra wrote: Ok, thanks. I'll give it a try.

Ashasekayi Ra wrote: So, we would send you a model that had two armatures? One that would call the pelvis bone "mPelvis" while the other calls it "PELVIS"? Asha: Almost, basically what is need you to do is to copy your current joint hierachy (all 23+bones) to a new hierarchy (so your file will contain two sets of complete joints used to weight your skin - one that is mapped to the current skin and the second newly created hierarchy, then you need to rename the nodes in that new hierarchy to the collision volume names that are in the avatar_skeleton.xml (e.g. PELVIS,BELLY,CHEST,NECK,HEAD etc) and then weight your skin using the joints from new joint hierarchy - containing the joints you just renamed. Export not only the "normal" joint hierarchy but also the new collision hierarchy.

The collision volume is just another joint ("collision volume" is the name Linden used waay before my time, I agree it is confusing) - basically mimic the joint hierachy, rename the nodes to the collision volume names that are in the avatar_skeleton.xml and weight using the new collision joints. Export not only the "normal" joint hierarchy but also the new collision hierarchy. Drongle McMahon wrote: Likewise, I would be interested if anyone can explain what this means.....what is a "collision volume"?....and what Collada elements is it supposed to correspond to? I can't find this term in the Collada specifications. :matte-motes-confused:

Hi there: I'm doing some research into one our open mesh issues, and one of the options is that we're looking into supporting rigging to collision volumes, BUT we need a rigged mesh that is weighted to the avatar collision volumes. The idea is that this might scale to match the morph distortions and as such might be useable in other areas of mesh ...but I need some sample rigs that have had their skins weighted to the collision volumes. So how can you help? The general approach is to create a hiearchy of collision volumes with the names of the collision volumes contained within the avatar_skeleton.xml file. Here's an example of the pelvis bone name and the corresponding collision volumes name from the avatar_skelton.xml: <bone name="mPelvis" ... >     <collision_volume name="PELVIS" ... >   Once all the collision volumes are in your scene, the skin needs to be weighted to those volumes/joints and exported to a .dae. If you would send that .dae to me (prep@lindenlab.com) -  it would be very helpful! Thanks, -prep  p.s. from followup clarification: The collision volume is just another joint ("collision volume" is the name Linden used waay before my time, I agree it is confusing) - basically mimic the joint hierachy, rename the nodes to the collision volume names that are in the avatar_skeleton.xml and weight using the new collision joints. Export not only the "normal" joint hierarchy but also the new collision hierarchy.

Marcthur Goosson wrote: I always make physics myself. In general I use planes. The uploader resized/replaced those planes automaticly to the boundingbox of the mesh model. Since today this does not work properly anymore. When I load my physics dae I see the replacing/redimensioning and immediatley the calculate button greys out. I tested with using the physics dae as mesh model and the same file as physics, no problem at all. Mesh project viewer 241391. Any thoughts about this ? Thanks. Can you post your SL log? There is most likely some info in there about why this is occuring,.. -prep

Ashasekayi Ra wrote: While browsing BlenderArtist's site today for new addons, I saw that Jester_v01 updated the "bone weight copy" script from Blender 2.49 to work in Blender 2.57. The script copies weights from one model to another model (even if the vertex counts are different). It's great for making clothes for an avatar. You can download the script from this thread. However, the script doesn't work with the latest Blender 2.59. PKHG pointed out that there has been an API change. After poking around in the file, I found that you only need to change two lines to get it to work with Blender 2.59. Line 77: WSTargetVertsCo = [v.co*targetObject.matrix_world for v in targetObject.data.vertices] Change to: WSTargetVertsCo = [targetObject.matrix_world * v.co for v in targetObject.data.vertices] Line 106: v.co = v.co * baseObj.matrix_world Change to: v.co = baseObj.matrix_world * v.co Woot! Awesome news. -prep

Utilizator Mode wrote: when uploaded my mesh, some vertices fore some reason have completely different weight maps than they had in blender, they are asigned to the right bone isntead of left. it cannot be an error on my side because i simply only riged one half of the model and than mirrored and applied all the weight maps, the model deforms perfectly in blender and there are no anomalies, i double checked everything and there is nothing wrong with the model, but when i upload it i get a few vertices following the wrong bones for some reason this is really annoying because i spend all day and a lot of L$ reuploading the model and trying to figure out what is wrong with it, no mater what i did i always got the same exact result, i tried deleting the half of the model that glitches and mirror a fresh half of it with all the weight maps but it didn't solve anything. i am wondering if this is a problem with SL or is it a problem with blender's colada exporter. has anyone ever had this or know whats going on? help would be apreciated, i also tried posting this issue on jira but its a ghost town  Typically when I see an errant vertex weight like that, it's because the vertex used did not find a proper weight in it's lookup upon import - so what this means is that if the importer fails to find an weight for a specific vertex that you've specified, then we fall through to our (current implementation) of get nearest vertex and uses that associated weight list. So what you end up with is a weight that pulls the vertex to an incorrect bone. What you can do is make sure that every vertex is in a group and weighted in blender, that way the importer won't fall into that bit of code. We should eventually fix this failsafe - probably I'm looking at replacing the current code w/ topological flood-fill that searches for nearest verts as well as changing the lookup to use the indices instead of the vert positions. -prep

MaxTux: email the minotaurs .dae (prep@lindenlab.com) - Without actually looking at your file, I'd imagine that there are unweighted vertices and so the code is falling into our nearest vertex code (which should actually be replaced with a function that does a surface fill to determine the nearest vertex, versus the current pure distance check) and that would exhibit the issue I see in the minotaur picture. It doesn't look like we log out any information if there are vertices unweighted when a rigged asset is imported either - so I'll add that. Thanks, prep 

Rusalka Writer wrote: It is still hugely failing to work, even when the only thing I'm wearing is a single pointed-toe leg. So your av is failing to retain the pelvis offset ... is there anything other then what's listed in the jira that your doing (if i could have a concise set of steps to repro with, all the better). Thanks! prep

Thanks Rusalka for the assets - see my comments from the user group about having only one rig with joint offsets. -prep

Rusalka Writer wrote: Yep. Sat down, stood up, sunk in the ground. Rusalka: Open up a jira and email me your rig to test with (prep@lindenlab.com).