OptimoMaximo

Honestly, yes. Every time a new project had to be started, i was there with this feature request. I was at the mesh development meetings asking for this. As i already stated in other threads, i'm much older than this avatar shows in SL. edit: i forgot that i was in SL also when sculpts were introduced. But at the time i didn't know i could make requests... that always fall in the void. On a side note, everytime a new project starts and we make requests, i am there. But then i see the low-end compromise LL ALWAYS chooses and i don't go back to the next meetings, i admit my fault in this.

Read more above in the thread and correct the aim. I was the starter of this material support issue. And it's not about attachment items only with clothing, my reasons are way broader.

No you can't, as Vir said, since bake on mesh isn't aware of what materials are in the first place. You should have the normals and specular maps for each garment to layer in the bake and perform the merge yourself, which is impossible as you can't have all texture clothing possible to create all possible combinations. The problem with this is that, currently, this addresses only rigged/avatar attached content. Thanks for joining in.... Put yourself in line since this is a feature *I* asked for, way more than one year back. Making alphas for best selling products take minutes to Homo Sapiens, maybe Erectus like you need more time. The actual issue at hand is that alpha cuts just behave horrendously, with gaps between pieces (thing that *I* posted a solution to, in these forums, FYI) and it just makes near to no sense, since a alpha mask can cut off parts more precisely than a bunch of separated objects with 8 faces each. One draw call for the mesh and one for the mask, as opposed to one draw call per avatar slice plus the mask. But again, this would render as effectively proficient IF materials may be involved too, otherwise the onion layers for layered textures will remain with the million polygons they bring with them. Which relates to the only thing you got right since the time i read your posts: at current state of things, this feature is just reviving old crap that looks like crap. Oh wait, it's something *I* wrote in a post earlier than yours, and said it upon feature request time more than a year back. @Cathy Foil The problem with this is that the initial request was for texture layering. You might recall me asking also for a secondary UV set for lightmapping, but no multiple UV sets so i folded over just layering textures. And i also expanded a bit on this, since my request was aimed at ALL mesh content as a base implementation in order to use it on static meshes too. Being free to tile materials on a mesh and have an untiled AO on top would save a lot in texture resources by tiling without dropping baked AOs. Same or similar would go for characters, where one might layer an animated texture on top of a skin. Instead of digging in the server stuff, they might have worked (fixing and improving) on the rendering side of things. Modern development makes extensive use of shaders for this reason, lighter weight and render effective. Before someone pops in saying "but SL has no shaders, it's got only a material system"... the material we use IS a shader, the ONLY ONE available. Maintaining and updating a shader is common practice in every software development, but it's just easier to recycle what's in place as is to deliver it on avatar attachments. With LL, the compromise toward the lesser is always the one that wins.

Exactly For the same reason you list possible uses for left/right arm textures, you may also consider that some other extra-uses may come up, like hair makers as well as genitalia makers occupying the bake_hair slot. I'd remind you that, as far as i understood, the operation is done on a per avatar basis, on the flagged mesh. Basically you flag a mesh to be part of "hair" and the baking happens on those parts. Hair makers might not be happy to know that the mesh body's HUD has turned their hair into a bunch of buttons. And fixing the hair with the hair's HUD makes their body's control HUD a pile of hair. Not mentioning the case of genitalia makers, you get the idea... Just possibilities, not saying it will happen for sure. It is a good idea about reducing textures on HUDs

I don't tihnk so, reading Vir's posts again. The system will use a limited set of baked textures to as many body parts the system clothing allows, per avatar, per flagged mesh attachment. Baked textures on HUDs would eat up a slot that may be used elsewhere. The alpha masking is the only benefit i can see so far about this feature, newer mesh bodies may take advantage of this, including non human avatars. Alpha masks might become a new type of "applier" if the creators aren't too lazy to make a little effort for an update on their best selling items. i agree with you entirely, an avatar with alpha masks is easier and slimmer to develop and maintain. It also avoids the gaps between body slices at high altitudes, limiting the issue to fewer and smaller areas.

oh i guess then you want to use Project from View in Blender Set an orthographic view (top, side, front, etc) and hit "U" on the keyboard and choose Project from View Be careful to select the faces you want to make an island for when you do this procedure. Keep doing a new selection and the project from view untill you've got all parts' UVs

This one here http://www.robinwood.com/Catalog/Technical/SL-Tuts/SLPages/WhiteHalo2.html

With appliers, if you wanted, you could make a leather top have its own material, with normal maps and specular maps too. With the bake service, instead, you no longer even have the option. Moreover, the mesh bodies have relaxed UVs to avoid the classic avatar's sides and shoulders texture stretch, reason why the same skin has different appliers for different bodies, since some key features locations like the belly button or the nipples have been moved off the default place by such UV map relaxation. This will make system clothing from the past useless on avatars other than the classic, those for mesh avatars will need a rework for each body anyway. It saves time in making the scripted applier's configuration, that's for sure, but it's killing the purpose of their own materials implementation.

In the average human avatar HUD, the specularity of the skin texture is controlled by this "shimmer" value. This will be rendered useless since the diffuse textures would be merged with clothing layers'. Now if you don't see a reason for materials on human avatars it's ok, but just take a look around in SL or flickr pictures, many use materials on the skin. Perhaps tattoos won't be a problem, but what will happen to other texture garments baked on top? And this is only the avatar rigged attachments side, when i stated in a post above that creators asked for a layering system, i was there the day they announced it and i asked for it myself. A more comprehensive layering system on mesh objects would have proven more useful in a broader range, including static meshes. I wouldn't go as far as normal maps blend options for these layers, that would be awesome but i realize it's asking really too much. Yet the Lab's reaction to a request is the bare minimum, least committing and cheapest of all the recycles they could do, which totally neglects a newer texturing feature in favor of a drag-back-to-2006 solution.

Yes it is, the effect vanishes with a graphics quality increase, usually. However this won't fix it for everyone. Creators can't expect people to change viewer settings to display stuff correctly, it's the creator's role to ensure that the item can be displayed by the broader audience possible.

Anyone will write it off as unusable, since this baking service simply trashes materials. With all the shimmer and other material properties already embedded into the onionskin avatars' HUDs, they will keep their system and send the bake services into oblivion. Useless feature and useless work on LL's side, if they're implementing this revived obsolescence.

That-s a problem with alpha blending. Not only it makes a hard render time on viewers, since there are so many layers, but the Z depth alpha sorting doesn't help. Try changing the alpha mode on the textures. Also, make sure to use TGA format 32 bits to embed the transparency on its own channel for better edges, and follow the tutorial in Beq's post in this recent thread here (last post) This should help achieving the fluffiness your fur texture needs from the alpha, which in a TGA format image can be much better quality than in a png. This way you avoid white contours and washed out semi transparencies

In SL, setting up a material on a selection of faces will translate into a separately texturable surface. You can have up to 8 materials per Collada file. There aren't shaders to work on, its only one shader. It's an odd mix between the legacy pre-rendered diffuse color only, and a spec/gloss approach. You can read about tech specs here That is done via scripting, if you are planning on having the object do something, say, on click. Just run a google search for LSL scripting. There are many free examples available too. In the (hopefully) near future we willalso have the introduction of AniMesh objects, basically rigged animated objects that don't have necessarily to be attached to the avatar itself. So, rigging first. Working with Blender, your best bet is to buy Avastar add-on. Which also helps with the compatibility issues between Blender and SL.

you basically asked for a similar planar mapping behavior you have in SL to work in Blender, as i understood it. Probably i should have mentioned that this doesn't make the transfer to SL as it is, it's a texturing method that, for SL, still needs you to make UVs and bake the resulting texture. This is actually a texture mapping method to project textures regardless of UV orientations and seams. For rendering, it works without UVs too. Making UVs for a bake is a necessary step to obtain a usable texture in SL edit: of course my example was using a procedural Blender texture, you should put any image you want to use as texture there

You are not mentioning anything about the exported file format you-re using Assuming that you're using Avastar with its .anim exporter, you should make sure that the arms that need to stay firm have a rotation change between first and second frame of your animation, in order for the scripts to store it in the file. Otherwise it will just skip the limb entirely and let the animation slot empty and, as consequence of this, in SL that arm will keep being animated by one of the animations that is playing already, no matter if your animation is higher priority.

Instead of using planar UV projection, try to use a object using cube mapping. Scaling the texture object sizes the texture, scaling the object keeps the texture consistent. edit: found some time to make a little example image

interesting behavior though

If you refer to the second one, it's the same object scaled up and with transparency. If done with mesh, making the extra copies randomly intersect their surfaces in and out of the base opaque textured object can help achieving some "fluffy furriness". As it is, it looks like my new glasses where shattered under a truck... i can't really tell how blurry the texture can actually be inworld though. The first one also looks blurry in the picture, but i can definitely tell it's a fur piece of clothing

IMO then, all is fine. In the end, the physics shape is needed for physics, and rezzing a cube on the floor doesn't use any. Probably it's a position rounding that the viewer does when rezzing on a surface that needs recalculation because of the object rotation, and to avoid that it just adds some room on the vertical to the "default" surface (without calculating its new position) axis like a precaution. Just as curiosity, if you take the 66 deg turned item back to inventory and rez it back in such state, does the rezzing keep adding extra height?

Does the rotation affect avatars walking on the floor surface too?

Yay great!

Line up your two objects in Blender, then CTRL+A ->Apply Rotation. After this you can try a new export. Let's see if it solves the issue

No, that applies to any content to upload to SL since Bento was released. Mayastar can also be great for character development if you plan on using the default shape as starting point with fitmesh, which is not limited to copy the default avatat's weights. if you edit the joint positions, do not expect the shape sliders to work exactly the same. when you edit some sliders, notice how the normal animation joints stretch by using their scale, their location in space results from this

Yes, sliders always match 100% between Maya and SL. What is happening is the lack of collision volume data , as you say: Don't remove collision volume bones, just let them be and don't weight paint those you don't want. At the end of your weighting process, before you export, make sure to remove the unused influences: Skin menu -> edit influences -> remove unused influences This way the skin cluster won't include the joints names that you didn't want, keeping Mayastar's system intact Max influences in the skin bind option can go up to 4, no more (another reason for weird deformations), maintain max influences checkbox is better to be ON. Allow multiple bind poses is useful to have ON if you know how to take advantage of it, otherwise it's pretty irrelevant NEVER EVER freeze transformations on any joint, move them around with no rotations involved and you'd be fine

First of all, what Maya version is it that you're using? Older versions have a little tweak to do (pre 2010 anyway) before things work in SL. Collision volume bones not only scale and move, they also rotate a little if not already rotated in their bind pose. A little set of screenshots both in Maya and SL (on beta grid so it's free) would be useful to try and see to figure out what might have possibly gone sideways. I've made my own avatar and many other rigged products on many different mesh bodies, and all has always worked with no flaw. Also, a bullet list of your procedure before exporting would also help to spot missing steps