OptimoMaximo

Normally, yes. But SL doesn't have an actual object instancing system. You can notice this in most of fbx and collada exporters, there's an option for keeping instances, where Avastar's turns the instances in actual objects upon export. An instance, by definition, is a transform node carrying some other object's shape node. In Blender you can see the object/shape separation when you rename the item in the object tab, in its mesh data the name doesn't change. If you export using the default collada exporter, the name you write in the mesh data panel (the shape node) is the name your uploaded object will have (assuming that this detail wasn't changed over the time i last used Blender). This system needs a mesh referencing system to work, and as far as i know, each asset you rez from inventory gets a new unique UUID, making it virtually impossible to relate to any other object on land (i think). I guess it should work if we got the chance to do a "duplicate special" to recycle the same UUID.

Not at all, UnrealEngine4 refuses to load assets with too high polycounts (due to how it manages assets import) and it's documented that it's best to work on shaders rather than geometry whenever possible. In SL, the exact reverse is happening. Since we don't have a fully featured shader to work with, much detail needs geometry to actually pop, ie height maps using parallax displacement rather than a tessellation based one, would sensibly increase performance and perceived detail depth without actual geometry on the object, within certain extents of course. In my opinion, modeling garments for SL should be very similar to the high definition games of the past, where only blinn materials were used and the height maps weren't an option yet. Model a high resolution version of the clothing, add some sculpting on top and when all the details look as intended, perform a retopology. Here, my own criteria to determine when "it's enough" is by observing the main details' silhouette , say a jacket folding. When i get a very spikey representation of the original silhouette, i add one subdvision level. I also try to combine overlapping pieces on the high res model into one retopoed surface, so to avoid the fuss of intersecting pieces (and hidden geometry) wherever it's possible. Then baking the normal maps should take care of the main detailing rounder shades (some geometry + normal map) as well as those too small for affording dedicated geometry. Frome here, all texturing work, either it be realtime material or a pre-rendered (baked) just adds the baking time to the procedure. The only thing that changes a bit from the old gen workflow is that in SL we can't afford to remove too much geometry on the areas between the joints (the bending areas), even if they aren't actually needed for the deformations. (Blendshapes/Shapekeys were normally used to define the shapes for different character models, thing that SL doesn't support, resorting to collision volume bones.) Why? Because of the fitmesh system: collision volume bones need geometry to affect the general shape and aren't intended nor placed near the bending points on an avatar. So a last cleanup that would otherwise be performed, here just drops. Also, consider that the sliders/collision volume bones would inflate/deflate the clothing vertices, giving again a spikey look. And that's where optimization falls apart for clothing rigging. It requires one more subdivision level, meaning newPolyCount = currentPolyCount * 4... and doing so polycounts just skyrocket. However, even with this extra subdivision, if i worked wisely, i don't get any way near the half those enormous polycounts i read from the other posts. So depending from the complexity and how many highres parts you'd be joining into one retopo surface, you could get a varying range between 10k and 30K triangles for a full outfit (keeping the numbers very loose here, assuming the max model roundness possible). Again, if you want to catch all the 20 meters of folded fabric around a 1 meter circumference, you will need many more triangles and the fewer you have, the more jagged its silhouette edges will look. Here it's your call.

i somehow missed the link to see the actual devkit files. First analysis: From the file creation dates, assuming you haven't saved over this package's blend file, the time stamps indicate that this character was made in Maya, exported to FBX, then a 3DSMax scene was created and for last, almost one month later, the blend file. This led me to read some infos when i opened the Blender file. First of all, this was imported and bound to an Avastar rig: The bones shapes and the main controller shape + name is unmistakably from Avastar Secondly, the character was rotated from the original orientation to fit Avastar's, but the rotation wasn't applied. It should work properly also this way. So i guess its intended use is with Avastar anyway I tried the update feature, but it didn't work. The skeleton just collapsed, so i went on deleting it, making sure the character was in TPose first. Added a new avastar only rig, and simply went to the model's modifier panel to re-attach the Armature modifier and it goes back to a working order with a similar structure. Collision volume bones are hidden by default but they're there. Now this should work properly with Avastar. Step back, without Avastar: We have an extra bone that will be listed in a default Collada export, the Origin. So i would go into edit mode and remove that one first Back to object mode, we must have the character facing the +X axis then apply Rotation (CTRL-A-->Rotation). This will not affect the pose mode rotations, just do not apply the pose as rest pose. Now, the problem resides in the following part: As you can see here, collision volume bones come packed with custom properties that derive from Avastar packaging, some of which are needed to simulate features that Blender doesn't natively support, like binding to a rotated or, worse, scaled bone. All things expected to be in place by the mesh system to work. Here, you can see that the inworld default scale value is 0.09, and that's what Avastar is going to write instead of the values you can read in the N panel. However the default Collada exporter won't export those from the custom properties section. I remember that Gaia Clary had a video about her Avatar workbench to work around this issue, but i don't remember what was about for myself. So your mesh squashing is most definitely due to this, since you're not using avastar to deal with the custom properties needed for the fitmesh system to work. You have two options i think: a) you use the Avastar version, doing the update as i showed above b) you find that Avatar workbench "trick" to be able to export that data from the native collada exporter and follow the second method i showed here. I personally would add a third option, but it's totally irrelevant to the matter at hand.

Sorry for the delay, I've had some serious issues on my pc in the last week and i couldn't check on anything. Unfortunately, i don't have any more ideas coming up right now.

Good to hear Have fun animating!

BVH files are intended to describe the skeleton and an animation attached to it in a text format, was born and developed for biped animation, meaning for characters. Plus, linksets do not work hierarchically. To answer a question from another previous post, about the measurement unit used in BVH: Theoretically, meters. SL instead features the expectation that the bvh file's character comes in as a centimeter scale avatar scaled up to inches (*39.37), Y axis up and +Z forward, to then compute it during upload and converts it to meters, Z up and +X forward. You couldn't do avatar animations to create the illusion you were thinking about anyway though, bcause hip translation is limited to 5 meters range in all directions

Easy enough: in the HIK interface, click on the empty area around the controllers map until all controllers highlight selected. Keyframe Rotation attributes. Then, go on and select the hip controller alone, and then keyframe the Translate attributes. From this moment on, autokeyframe works consistently to this initial keyframing you just did, and doesn't interfere with anything. Thank you unfortunately the conversion to binary data caps the values, so that's really the max precision allowed by the anim format. However, notice that the exporter also supports different FPS settings. Not all the available rates in Maya, but you can animate using 15, 24, 25 and 30 FPS. Switching your animation now from, say, 30 fps to 15 will readjust the timeline and your animation will still playback the same speed in Maya as well as the exported one in SL, with the difference of a lighter weight .anim file (just make sure to fix the animation range accordingly to the new timing) Also, you can downsample an animation by setting the exporter to sample every N frames. This feature only works on 24 and 30 fps setting.

Something that can't be stressed enough is the shape consistency between your avatar inworld and the one you animate with. If you use Mayastar's shape editor, it's possible to configure your own shape or any other most commonly used shape, with better proportioned limbs length (better than the default, that is). The joints offsets play a big role when it comes to exactly place the hands (or feet) somewhere. You should just change your avatar, which HIK makes simple enough: export the animation in FBX format and reimport it in the corrected avatar's animation scene, then retarget. HIK will do the rest for you and readjust the target character to closely match the poses beteen the two differently shaped characters... some editing needed, but at least you won't trash your work so far. IMPORTANT: after the process of reshaping your avatar in Maya, before you generate the animation skeleton, make sure to lift the avatar mPelvis by the amount you need to see his/her feet above the ground. Once you generate the animation skeleton, the avatar's height is established and the current feet position is stored as the floor position. If the avatar shows the feet sinking through the grid floor, that is the current floor, any subsequent lift to stnd above the grid floor will result in your avatar floating in the air. Remember this tiny deail and you'll be good All this was necessary to also allow totally custom characters with diverse (also non human) shapes All the involved body parts should be keyframed following the same principle explained for the hip, except for a detail: no translate attributes keyframes other than on the hip. Since Python in Maya is a bit slow with getting data from Maya's core AND doesn't sample a few pieces of data if the animation doesn't actually playback on your screen, i opted out for the most lossless solution that was to directly sample joints data upon serialization to file. Therefore, there is one cycle for each single involved joint, rotation data first and, if found, a second cycle for position data, one cycle for each involved joint. Using the recommended settings i show in the instruction video, it becomes very fast. All good there then, just checking No problem

I see the position keyframes on the hips didnßt come through, and the explanation is quite easy, fortunately. Before sampling for export, your animation is being analyzed to filter out unused data. This filtering happens by sampling the first frame of your animation against the fifth. If no changes are found, the bodypart is dropped. Your animation clearly begins totally static for more than 5 frames on the hips about its position data. Just make sure there is some position motion in those first frames, even quite subtle, a 0.01 would suffice. Also, from the video i see a quite big grid. You may have edited the grid settings and it is fine, just make sure in the general settings to keep the linear units in centimeters, too. This should fix your issue.

I have a group for MyAniMATE users. I've run into video card issues yesterday so i will not be able to log in for a few days but i will send invitation as soon as i can. Also, the update includes 3 sides of the plug in, so it will take some time yet, considering also the testing Sounds like a good checkpoint!

Sorry for the delay. Aside from the instructions videos, you have to be aware of the basic differences that govern the BVH export scene and the .anim BVH is a common standard that by definition has the Y axis up and the Z forward. However, SL internal up is the Z axis and forward is the +X axis. Therefore the two setups are incompatible in their basic world orientation. Moreover, the character scale differ between the two standards. BVH for SL assumes a character in inches, while .anim implies the use of "units", see them as meters or centimeters, it's the same. In my setup i chose meters to allow up-to-scale animation over objects. Due to how Maya works, for now couple animations aren't supported. It's in my plans to deliver a big update that should also address this application. You can use a classic rig as well. Be careful not to delete partial joint chains from te bento appendages: either the whole branch or leave it. The update i was talking about will address this in order to ease the process for animesh objects. The animation loss you see is the minimal possible and it's due to how the animation needs to be compressed into binary values: during conversion from signed floats to unsigned ntegers, resulting converted numbers get "floored", meaning the decimal gets truncated to become an integer, generating an implicit imprecision...which again is really really small, given the two ranges of conversion (-1.0/1.0 into a 0/65535 value range) MayaStar animation rig is a very old HIK version that screws up quite adly in these newer versions of Maya. Cathy Foil has her own set of videos among which there is the instructions to upgrade the rig to the latest HIK vversion. With MyAniMATE, IF you're using the BVH set up, you can follow that tutorial but it won't work to export .anim, only bvh export will. To use .anim, you necessarily need to generate a new skeleton specifically for .anim format standards (follow my intro videos on that)

Thanks! So now you can forget about the TPose at frame 1 and work up to scale, with the same character orientation that a script would expect as zero rotation sit target... quite a bit of benefits =) Please make sure to watch the few videos linked there!

Well, if you start all the animations from a single, offset pose you shouldn't have trouble firing complimentary animations and, to be honest, at the moment of standing up, it looks better if your sits are offset to the back, so that the avatar doesn't jump on the furniture's top. What version of the exporter are you using? From the error looks like the BVH exporter 1.5, Cathy Foil has fixed these types of issues releasing the BVH 1.5.5 version. Perhaps your installed version is the troublesome one. On the other hand, the inconsistent and unreliable behavior of BVH files upon upload in SL led me to write my own .anim exporter, so i hear you well there.

This happens because of BVH uploader in SL. If a bone doesn't rotate for a certain number of frames (depending on the file's fps and number of frames), its information gets dropped. Your best bet is to make your character stay standing up and then animate the descend into a sit in order to heavily rotate all the bones you need to animate in SL. At the end of the process, you would loop only the section of animation she has to loop (or just the last frame) so that she stays sat. You saw how lifting her feet made the legs come through... it's because the joints are clearly no longer at zero rotation in this new pose and the uploader reckons that, keeping that body part animation.

I suppose you're using the weight painting tools only. In the left side panel (T), among the weights tools, you have one called "Levels" and another called "Smooth" In my case Smooth is greyed out. Levels is a great way to smooth and proportionally shrink/expand the vertex group's size. Smooth does a simpler smoothing. You could try implementing these two tools to smooth out the shoulder areas. Also, the Fix Deforms button is a good way to help on small areas. Just use it on a smaller selection of badly deforming vertices while in weight paint mode

Alright, i try to explain this issue: what you're trying onto is a dev kit that was most likely made using Avastar. The problem in Blender for SL stuff is that Blender wants your character facing -Y axis like in your picture, whilst SL wants the character facing +X. During export, Avastar scripts do their thing in order to convert Blender's orientation into a SL orientation, which is represented by the skeleton Z axis rotation you've found on the object mode skeleton only. My explanations, in my previous posts, were comparing the 2 workflows. So, IF you're not using Avastar: Make sure you're using Blender 2.78 (the latest version seems to have problems with rigs) Take the skeleton in object mode and set all rotations back to zero. The rig will turn with the character attached. Take the character and Apply Rotation only Make sure that ALL bones in pose mode are set to zero rotations as well Bind/parent/attach to skeleton and do the weight transfer I'm sorry to have added up on the confusion, I often use Maya terminology. Binding to skeleton is the same as parenting to Armature in Blender. This rotation discrepancy is due to Blender's limited handling of mirroring when it comes to weights and posing, which can only happen across the X axis. That's one of the several reasons i abandoned Blender also for my SL stuff.

I'm assuming that you're using the HumanIK rig, because you said that the neck was going crazy if you tried a copy/paste key. The safest method to copy a pose from a frame to another is to use the no Update feature. Place your timeline on the frame where the pose you want to copy is, then MiddleMouseButton drag to the involved frame. The character will not update its pose and you'll be free to grab the controllers and keyframe them manually on the spot. A HIK rig is being created in absolute mode and a simple copy/paste won't work as expected.

Alright, so IF the devkit came in facing -Y with a rotation of -90 on the Z axis. What avastar does, basically, is to make the default working Blender orientation comply to SL's requirement upon export. When using plain Blender, no Avastar, you should make sure your character faces +X axis in the first place. This breaks any skeleton or weight mirroring operation, so you should do this right before the export. You should not apply the scale at any time because a) you're not scaling the character b) collision volume bones DO have scale information that is not 1,1,1 in its rest pose So, i would suggest you to re-import the devkit, turn all rotations to zero (type the zero values in the transforms, do not apply rotation) and then bind to skeleton.

How dare you inform people of the good practices that make general 3D modeling skills necessary instead of letting us free to whip in any sculpted model and be praised for the "quality" by the customers! How dare you say the smooth curves the item i just bought was made out of bad practices, it doesn't look like your petty 90's game models!... i know what you mean, i was being sarcastic there...

Blender's shortcuts are contextual to the view where you're hovering your mouse, make sure you hover it on the 3D view when you hit "i" and a list of those options will appear. It is a Blender's default behavior, Avastar isn't involved

@ChinRey This kind of hurt comments, aren't they?

Indeed, i'm saying that if the geometry doesn't make a face, Maya impedes its creation or permanence. Of course i can create as many faces in as many disconnected places i want.

Yes the warning says it-s a high triangle count and it's throwing a warning you could ignore, it says. Aside from the triangle count, Avastar can do its job here. I believe that avastar copy weights from meshes is only intended for the classic avatar it provides and that could be hidden from view now. I'm not sure it accounts for your devkit meshes at all. To me, you should do the manual procedure, unmistakably doing the copy weights yourself. Another thing i forgot to mention, it's easier to have trouble if you bind a mesh that still has transforms, apply all of them prior to binding (CTRL+A apply rotation, scale and location). We're almost there figuring out what was wrong, don't give up =)

Yes please, i've just seen this message

The impediment isn't in the cutting, Maya impedes the formation of "left over" geometry if that geometry doesn't make a face.