Chip Midnight

Mesh (and prims) uses a different shading and material system than the default avatar does so depending on lighting conditions there will always be a bit of a mismatch even if they're both using the same texture map. In very flat even lighting it's not too noticeable, but becomes more noticeable the more directional the light is. There really is no fix for it other than using a mesh avatar.

As far as I know, left and right pecs and butt are the only bones used for physics. The also largely control the breast and butt appearance sliders.

Someone on SLU tipped me off about the show collision skeleton feature in the develop menu. That definitely helps a lot. The sliders are scaling multiple bones so getting the right rigging is proving to be quite a challenge. It would be great if there was a list that explained each appearance slider, which bones they're scaling, on what axes, and what percentage at max slider value.

I'm rigging a mesh avatar for fitted mesh and am having trouble figuring out which bones are linked to which appearance sliders. Belly size for example seems to effect quite a bit more than just the BELLY bone's area of influence, extending into the hips and crotch even though those vertices are not weighted to the BELLY bone. The HANDLE bones in the download files are not weighted at all so I can't see the normal range for them, but the love handles slider in appearance moves vertices far outside the range that I weighted for them. What other bones is that slider scaling? So is there a comprehensive list or discussion anywhere that describes the bones each appearance slider is scaling? As it is now I'm having a hard time getting my mesh to behave the same as the default mesh in some areas, particularly belly and love handles.

I'm rigging a mesh avatar for fitted mesh and am having trouble figuring out which bones are linked to which appearance sliders. Belly size for example seems to effect quite a bit more than just the BELLY bone's area of influence, extending into the hips and crotch even though those vertices are not weighted to the BELLY bone. The HANDLE bones in the download files are not weighted at all so I can't see the normal range for them, but the love handles slider in appearance moves vertices far outside the range that I weighted for them. What other bones is that slider scaling? So is there a comprehensive list or discussion anywhere that describes the bones each appearance slider is scaling? As it is now I'm having a hard time getting my mesh to behave the same as the default mesh in some areas, particularly belly and love handles.

You should use skin. Physique is outdated and is only still included in Max for backwards compatability. The default limit for number of bones that can influence a vertex in the skin modifier is 20 so I'm not sure why you're having issues. Have a look at the influence envelopes of your bones. You will need to adjust them manually if they're too small. Those will give you a good starting point but you will always want to go in and adjust individual vertex weights by hand. Just keep in mind that once you do that you can no longer use the envelopes. Their influence will become baked and no longer adjustable by manipulating the cross sections. You do need all bone names in the name_array of the DAE file. For fitted mesh that's now 50 bones. Open the DAE file in a text editor and search for "name_array". Change the number of bones to 50 and append the full list of bone names to the list. It doesn't matter if some are listed twice.

When skinning to the collision bones for fitted mesh you do not add the regular bones to the skin modifier. There's no need since the collision bones are driven by the standard bones. Depending on the version of Max you're using you probably don't need to go through the intermediate step of exporting by FBX and then converting. I'm using 2013 and exporting directly as DAE works just fine. Open the DAE that's incuded in the fitted mesh zip file in a text editor and do a find on "name_array". That's the part you'll need to edit in your exported DAE. Make note of the number of bones. It used to be 26, but now it's a different value. Copy all of the bone names between the name array brackets. In your exported DAE change the number of bones to the correct value and then paste the copied bone list into your name array after the bones that are already listed there. Repeated bone names are ignored. That's all you need to do.

Cerise you're a genius! That did it at last. Thanks!

That was a valiant effort! It detected them but didn't link so deleting the box didn't get rid of them.

No luck so far but I did manage to get them to show up in outline form using show objects owned by parcel owner. No luck selecting them. It my have corrupted on upload. It's flattened with one vertex that shoots down into the ground. There are three of them because I tried to rez it three times.

I just uploaded a rigged mesh I'm working on and rezzed it on the ground to texture it. It's invisible and unselectable. I know it's there because I can collide with it but I can't see it or select it. I tried highlight transparent and wireframe view and there's just nothing there. Tried in the current versions of the LL viewer and Firestorm and it's invisible in both. Has anyone encountered this? I'm at a complete loss on how to delete it. The same mesh worked fine yesterday. The new version had the UV mapping revamped and some tweaks to skin weights and smoothing groups. Otherwise it's the same.

For getting the SL rig into Max you can use Wiz Daxter's SLAV plugin. http://wiz-bg.blogspot.com/p/slav-3ds-max.html The default size set on the importer is 40. Make sure to set it to 1 instead. You'll avoid a ton of confusion. Once you have the rig you can refer to any max tutorials for using the skin modifier. This is a pretty good one though it's not specific to SL: It's part of a longer tutorial but the skinning sections are all you need.

Looks like weighting issues with some of the vertices. Check the the verts in the areas where you're getting penetration and see if they're being pulled out of whack by being influenced by other bones.

Swobbly Minogue wrote: Hi, I have a question related to RTT in Max, so will post here to save starting a new thread. I want to be able to bake a texture that results in my shadows starting from black and fading into transparency. At the moment my shadows start from black and fade into white. I would also like the background of the texture to be transparent too. Is there any way to do this in the RTT process? If not is there anything I can do in Photoshop with my baked texture so I just end up with shadows fadding into transparency. Thankyou. I'm not sure how you could do that with RTT since a transparent object wouldn't actually produce shadows. What you could do is take that grayscale shadow pass into Photohop and use it as a layer mask to control transparency.

Anakin Crystal wrote: Another question., how do i make the shadow darker , when i enable the shadows function, when i use skylight? Since a skylight emits an even amount of light from every direction it won't produce strong shadows on objects without areas of strong occlussion. You can make the light a bit more dirrectional by using a gradient ramp in the skylight's map slot. Or just add a directional shadow casting light to the scene and adjust the light's shadow density to your liking. You could also render a seperate shadow or occlussion pass and do the composite in photoshop where you can adjust the levels on the shadows.

In your screenshot you have RTT set to use existing channel 3 instead of 1. I'd add an unwrap UVW modifier to your object set to channel1, open the UV editor and make sure the UVWs are how you want them. Once they are collapse the modifier stack. Then apply your material and rebake the texture making sure RTT is set to use existing channel 1 (the little dropdown menu to the right of the "use existing channel" toggle), and that it's set to render to file only.

One or two things happened there. When you use RTT it by default will do two things you probably don't want. First it will add an automatic unwrap to your object on UV channel 3, and second it will take the resulting baked texture and assign it to a new material, replacing the material on your object and with the new bitmap set to use UV channel 3. At the top of the RTT dilaog make sure it's set to use the existing UV channel (1). If it previously added an automatic unwrap modifier to your object, delete it from the modifier stack. At the bottom of the RTT dialog check the box for "Render to file only" if you don't want it to create a new shell material and would rather set up the new material yourself.

To get the fully shaded texture including shadows and specular highlights using Render to Texture you need to render out a "Complete Map" rather than a diffuse map. Rendering a diffuse map out of RTT is only useful as a layer for compositing. If you want ambient occlussion as part of your complete map you either need to use a material that generates it (like the Mental Ray Arch&Design material with AO enambled in its advnaced effects rollout), or if you're using the scanline renderer you need to render an Occlussion Map seperately with Render Surface Map and combine it with your complete map in photoshop.

What do you mean by AO map exactly. Are you rendering AO using the render surface map feature or do you have AO enabled in a Mental Ray material? If using render surface map you'll want to take the grayscale image it generates into an image editor to clean it up and combine it with your texture map. When you bake maps using render to texture Max by default will apply an automatic unwrap on a new UV channel. If you've manually unwrapped the UVs you want it to use that instead of doing an automatic unwrap. Be sure to set RTT to use the correct UV channel. As for your diffuse map troubles you need to give more information. What material type are you using and how do you have it set up and which renderer?

Max 2013 is a bit over $4000, not $15000, and it does not export BVH. It can be imported for use with the Biped procedural animation system but there is no output. As disappointing as that is there's a reason for it and that's that BVH is an extremely limited and outdated format. Even SL doesn't actually use BVH. On upload it's converted to SL's own .anim format which stores more data than BVH can. The only reason it's the upload format is to make SL compatible with Poser since in 2004 a lot of people were already using it and it was affordable. As someone who's been making a living with Max and 3d Studio before it since 1992 I feel comfortable saying that it is worth every penny of its rather modest price. There are good reasons why Blender still isn't used much professionally and its price and bvh export aren't it. Blender is an excellent choice for SL content creation though and people who aren't already Max (or Maya, or SI) users should definitely use it over buying an expensive professional package if Second Life is all they want it for.

You can fix this without having to redo the skinning. In the Advanced rollout on the skin modifier save your weights. Use SLAV to create a new rig with a scale of 1. select the pelvis of your old rig and align it to the pivot point of the new rig's pelvis, then use uniform scale to scale the whole thing down to match the new one so that you can get your mesh sized and positioned the same relative to the new rig. Use snapshot to copy your mesh then delete the old rig and mesh. Assign skin to the snapshot, assign the bones of the new rig, then load your skin weights from the file you saved. You should be fine after that.

I asked and Avastar uses the same rig for both and does axis and rotation conversions on export.

Avatastar looks really good. One thing I can't tell from watching the videos for it is if you can animate with a custom mesh avatar after it's rigged. Is it using two different bone setups or is it doing axis conversions on bvh export? Ideally I'd really like to build a workflow around the tools I already have and know well before I give up and move over to Blender,

I don't think the preffered rotation order in MoBu really matters since it's only used to drive another rig but I'm a novice with it and could be completely wrong. I do know for a fact that there are motion builder rigs that work for SL output as someone was kind enough to send me one. I should be able to animate on whatever rig in Max and then retarget that to the SL friendly rig for output. I'd love to understand what's going on under the hood though. I imported that rig into max to have a look and built a rig out of editable mesh so I could match the bone axis orientations and euler rotation orders. I then skinned a test character to it and tried exporting as collada to SL. It was, er. interesting. The skin was zig-zagged as if every bone was rotated 90 degrees. It looks like what works for animation does not work for mesh rigging and vice versa. Is anyone doing both rigged mesh and bvh output from Blender? Is it the same situation there? If it's true across the board that rigged mesh uses different bone axis orientations than SL's animation system that's such a ridiculously bad design decision I don't even know what to say about it. My guess would be that since custom animation was added after the avatar system was set up that they did this mismatch on purpose just to make it compatable with Poser's bvh output. Now with the introduction of rigged mesh that decision is coming back to bite us all on the ass and we're stuck having to use convoluted workarounds and hacks. surely others have already banged their heads against this and have some insight? Anyone? Bueller?

I'm game but we should get Wiz Daxter's OK since SLAV is his commercial product so I don't want to step on his toes in any way. At one point I know he was working on BVH export out of Max but as far as I can tell nothing was ever released but a youtube video. I tested changing the euler rotation order on all the bones in the SLAV rig to match SL bvh files and then ran it through MotionBuilder to retarget a mocap file to it. It made no difference. The rotation orders in the BVH out of MoBu didn't match the SL files. I also tried enabling DOF (degrees of freedom) on each of the bones in MoBu and used it to change the rotation order and that didn't work either. This is all confusing as hell since I know there are motionbuilder rigs for SL whose BVH output works in SL. I don't think I have a future as a character TD. :matte-motes-crying: