AcidJuice

thanks for the answer. It is mesh.

Hello, Twice one of my demo item has been bought by one day old avatars. I feel that curious specially because this happened almost immediatly after i put it on the marketplace. Can that be some kind of copybots ?

Hello, I have looked at the create-case page, but i am really not sure about what option or category to choose here to indicate a syncing demand. Could you help ?

hello again, some tests : - a mesh based on the skeleton (skeleton.female.blend), composed of colored diamonds, in Blender and in world : Now, three configurations : 1/ the normal one (all stayed aligned as in the original blend file (this correspond to the previous snapshots 2/ mChest, CHEST and PEC are displaced 20cm toward X 3/ the same but with all cBones removed Here is the result for 2 uploaded with joint positions And here is the result for 2 upload with no joint positions and when you add 3 with joint positions here is the color codes : Globally yes, the mesh is crewed as you said, Medhue... and yes there is an impact when you add a second mesh (with joint positions but with no cBones). ... but i doesnt seem to be simple to understand how all these moves...

Thanks Medhue. Gaia talked about it online... unfortunatly my computer crashed and i have lost the chat log... What i remember is the following (but i may be mistaken) : - you need two meshes. The first one is your real mesh and the second a small mesh with one triangle - The first, the real mesh, contains all bones mBones and cBones - The second, the one tri mesh, containes only mBones - Upload the first mesh with only skin weights (and no joint positions) - Upload the second with joint positions - Wear the first mesh and then the second one If i have understood well (that's not sure), this means that you have to rig and weight in blender with the armature of the second one. I hope to have time to test it this afternoon... Another test i did yesterday : i used the skeleton.female.blend provided by Linden and just kept the armature in it. After that i made an avatar composed of small cubes. Each cube was placed near of each cBone and each cube was weight fully to this corresponding cBone. In that configuration, the skeleton stay 100% in place and i was able to upload it with "joint positions" with no problem, and sliders work well (and this is a good way to see skin movements when you move the sliders). After that, back in blender, i edited the skeleton and displaced only PEC bones in the x direction (a small translation only) and edited the avatar mesh and displaced also the corresponding cube. Uploaded it, and there was no differencies with the previous mesh inworld : all was as this was the exact same mesh and skeleton. Now, I did the same, but translating together mChest, CHEST, and the two PEC. Back in SL, all bones were bad. There were no "big stretches to point zero", but all bones were affected. It seems there are strange calculations in it... Next time, i'll do the same, but with colored cubes, so that we can see who goes where. ... well we are far from the collada files, now in the discussion ^^

For information, some other tests made with SLViewer (i'd noticed that Firestorm may have a different behaviour), on Aditi : As seen before, some fitted meshes can be distorded. The point is as soon as you've weared such a bad mesh, the other fitted meshes (good or bad) become bad after that... And you have to relog to correct the problem. So, this also means that there is no way to correct and test your meshes without a relog, as all subsequent meshes may keep the same problem as the first bad one... (dont know if this occurs all the time, but it did three consecutive times in this little test...)

Yes to use the sliders and to add some physics, eventually. Going further, i had a look at the collada specs https://www.khronos.org/collada/wiki/Main_page. But... wow... : ( and i have seen nothing really explaining the calculations that are done on these data : ( I have found some here http://www.wazim.com/ but nothing about restposes : (( Maybe they are application specific and... well... i wont find here which offsets or scallings the sliders apply in world... Any information on all these ?

Thanks for the reply Medhue. Surely, i do NOT want to say that anything, Avastar or Blender or others are not working... but i just try to have a better or deeper understanding off all these things, specially concerning cBones. And yes, to reply to your examples, Medhue, my aim is similar and this is just the point : how to well take part of this unique skeleton to make fun things... As examples too, below what i did recently and they are ok in world with conventionnal AOs. For these i did not used Avastar, but i usually use it too. The point is that sometimes i obtain a good weighting in Avastar and sometimes it's directly better using Blender's parenting with automatic weights. But, concerning collision bones, it is far more tricky... that's why i am wondering and hope to understand things better... As anecdote, i recently discovered that cBones behaviour is not "constant" : - I used a mesh with fitted bones, and it was distorded as i wear it. This was with Firestorm. - After many tries, I discovered that a log out/log in was necessary to have it working (still in Firestorm) - But when i changed my outfit, and wear it again, it was distorded again... - Trying with SLViewer (i installed it for this test), all was ok at the first time, just after the upload.... but... after that, i weared back my current mesh and this mesh (which is from a well known shop and so causes no problem) was distorded immediatly... and i needed to log out/log in again Curious, and plenty of experiments, sometimes, to obtain the result you want ^^

Still searching to understand, i did the following experiment (blender 2.75) : - Opening skeleton.female.blend from Linden package called "Second Life Avatar Skeleton" - Directly exporting it as collada file (using export presets "SL Open Sim rigged") Note that this file contains restpose definition in bones custom properties. Now i compare the collada file also given in the Linden's package and the file i've just exported. I consider here only the PELVIS and BUTT bones wich are at the end of the list and easier to find : - Original skeleton.female.dae : Controller section : PELVIS 8.252234 -1.159776 0.000000 1.296808 0.000000 0.000000 -6.250000 -0.000000 0.818665 5.825106 0.000000 -6.090700 0.000000 0.000000 0.000000 1.000000 BUTT 10.000000 -0.000000 0.000000 0.600000 -0.000000 0.000000 -10.000000 -0.000000 -0.000000 10.000000 0.000000 -9.670000 0.000000 0.000000 0.000000 1.000000 Visual scene section : PELVIS 0.118832 0.000000 0.023659 -0.010000 0.000000 0.160000 0.000000 0.000000 -0.016701 0.000000 0.168346 -0.020000 0.000000 0.000000 0.000000 1.000000 BUTT 0.100000 0.000000 0.000000 -0.060000 0.000000 0.100000 0.000000 0.000000 0.000000 0.000000 0.100000 -0.100000 0.000000 0.000000 0.000000 1.000000 - Exported .dae Controller section : PELVIS 8.252235 0 -1.159776 1.296808 0 6.25 0 -4.94039e-7 0.8186653 0 5.825106 -6.0907 0 0 0 1 BUTT 10 0 0 0.6 0 10 0 -7.30065e-7 0 0 10 -9.67 0 0 0 1 Visual scene section : PELVIS 1 0 0 -0.01 0 1 0 -1.50995e-9 0 0 1 -0.01999998 0 0 0 1 BUTT 1 0 0 -0.06 0 1 0 -7.54979e-9 0 0 1 -0.1 0 0 0 1 So... it seems that custom properties are not taken into account at export ??

A little complement... Looking at the collada files and blender parameters, i noticed to points : - The roll parameter of each bone is set to zero for the Linden model (which is not 'natural' in blender, it seems, as the roll can change as you move head or tail) - The product of bones matrices and rest pose matrices seems to be identity. Is that correct and automatically done at export ? And if yes, does that mean that custom properties give some kind of reference value, whatever your bones positions are ?

Hello, I recently tried to find some informations about Collada and bones (joints) definition, in order to understand well how to rig my meshes, specifically deform bones (as mBones are ok for me). Before any other thing, i have to precise that i am really newbie at math and matrices... and many other of these points... I discovered these explanations about Collada importer add-on, in Blender : http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.73/Addons. If I understand well, the inverted (export from Blender to Collada) calculation does not implies the same problem, as Collada's leaf bones definition is completly covered by Blender's model (yes ?). But in the other hand, Blender does not include rest bone definition as Collada does. And rest pose definition is "mandatory" in order to have a good fitted mesh behaviour in SL. I know the relationship between these two points is not so clear (or at least, it is not in my mind). But i am wondering and have some questions : - Collada files (in order to have good working fitted meshes) need to have a "rest pose" (maybe defined in the visual_scene section). - Linden gave us a definition (pos, scale, rotation) for avatar rest pose (found in the custom property panel in blender). And if these custom properties are not provided all is considered as identity matrices So, the questions : Rest pose definition is in some way bound to bones (or joints) definition in order to have a good mesh behaviour in world... what is relationship between them ? May we consider that rest pose values given by Linden must be used and no other one (due to some built in behavious, in world) ? How to create an armature in blender conformed to the rest pose definition ? Or another way to say that : is there any approch in blender to "emulate" the same concept of rest pose ? It seems that mBones does not need a rest pose definition... but looking at Linden's collada files, their rest pose is not the identity matrix... so why ? and why non fitted meshes work well with no rest pose ? PS1 : i know that Avastar "does the job for us", in many cases. But my meshes are often a bit "off standard avatar proportions"... and a better understanding could be good. PS2 : of course, i may be wrong in many things i wrote here...

Hello Bongo, Very nice head ! For your questions, i am actually working on nearly the same subjects... so i dont have all responses but here is what i can say : External head mesh parts (eyelids, mouth, ...) cannot be rigged. So, yes, you have to do some kind of animation : i guess, multiple mesh parts and showing/hidding them with a script. Concerning the UV maps. Classic sl skins are very close from planar projections (front, back, sides). So, you may study a bit how avatar meshes are seamed to do the same cuts on your model, then adjust your UV maps to avatar skins UV maps... a bit challenging (avatar's mesh is a lot of tris... no quads), but i did not found any other approch or tool that could do the job... Hope it helps...

Hello Maybe the last post for this thead ! All is still ok (in english settings) and i think we can consider that's stable now !! Many many thanks to all !! Have a nice day Lemon

Hello Whirly, I have read the answer given by Sabanco here https://jira.secondlife.com/browse/VWR-29033 I am not sure i understood him well. But few more indications about what i have found : - Scanf result is not checked in the collada libray (daeAtomicType.cpp i mentioned before). So if it fails, the resulting value may certainly be 0, or at least not the expected value - I have found a microsoft scanf implementation ! Not sure that the good one for me (many things on the web about that). But if i am correct, this is in the file 'input.c'. Here you can find the reading sequence of a floating point number (around line 1136 in my file... but it seems that i cannot upload this file here). To say short : - It reads the sign (if exists) - It read the integer part - It checks for a decimal separator - and read the decimal part and exponant if they exist But... if i am correct, if the decimal separator is not recognized (and this seperator is dependent on the local settings and on the file encoding format), the result will be truncated to the integer part and no error will be returned. After that i dont know if this 'shifts' the sequence of values in the dae arrays (as the decimal part is not read if the separator is not recognized). Well... i dont know where to search more...

Maybe yes Drongle... but i did not found any information about that... and i know very few about all this...