OptimoMaximo

It is just a resource waste, since the color on each pixel is what positions one vertex on the final sculpt shape. It doesn't deliver any increased precision, it's actually the reverse: this may induce color degradation and a mis-location of vertices, resulting in a irregular and not smooth surface. Continuous attempts to recalculate the shape from a oversampled texture leads to shape update attempts that aren't necessary and that may cause lag

Collision Volume bones are standard even before Bento additional bones came out, they are used for shape sliders and, as the name implies, determine the volume of the worn mesh. They can be animated using .anim animation format. You need a compliant avatar to begin with, since their location is established in the avatar already. The default avatar from Avastar works. And how exactly do you think to make 2 standalone animations to work together this way? One animation can't be aware of another animation rotations, it's something you "program" (drivers or scripted expression) in your own animation to work together as you wish. You must make your own animations involving wrist and the collision volume bone in order to achieve this result. What you're trying to achieve is called "twist joint" and usually needs to average the rotations between previous and next joint in the hierarchy. Animation triggers are not supported in SL (ie: if Wrist joint rotation >= X degrees run this animation, else run this other animation //// this is not supported in SL) The local axis of a bone has a direction, and that is what i'm referring to. In Avastar it should be the local +X of said Collision Volume bone, which should rotate around this axis (which runs through the forearm along it length)

You could do it by setting drivers on the collision volume bone, so that the local axis running through the length of the arm rotates 50% of the wrist's rotation. Such collision volume bone shold be weighted accordingly, and for a custom character it may work well. Another solution, that runs slower on playback though, is to drive the same collision volume bone through a scripted expression.

Dopesheet shows ALL animated objects' keyframes in the whole scene, so your best bet is to enter into the object's Action editor first, so to be sure you're working on the correct one. The options you're using aren't intended for bones animations in this context. After hitting the "i" key, you should choose one of the options about location or rotation. If the channel is missing, using this method ensures that it is going to be added. The COG bone needs LocRot so to add both channels to the only bone that really needs those, all of the others (except a few face joints) need only Rotation. More on this latter, if you're blending between IK and FK animation keyframes, sometimes you may want to keyframe a pose achieved with the help of an IK controller onto the affected FK bone(s). In this case, keyframing the regular Rotation won't work to keep that pose, for this reason you should use Visual Rotation option. If this is the case, make sure you do choose this option right from the very beginning or it won't work correctly in every circumstance.

Yes you can, but the avatar orientation assumption collides with Bleder's default "front" direction, so if you need mirroring features, you'll have to use Blender's native orientation, then before export you'll have to rotate both the skeleton and the mesh, apply the rotation and then export. However, if your goal is to make fitted mesh, plain Blender won't work for the collision volume bones on a generic SL skeleton. Your meshes will come into the uploader either heavily shrunk or exploded, because collision volume bones (what makes the garment "fit") are assumed to have a specific scale within SL while Blender's architecture doesn't natively support this (called bindpose). You should get the free Avatar workbench from the Machinimatrix website in orderto have the correct scale value be written to file. You can purchase Avastar from the shop (the sim is called JASS, easy to find from the inworld map) or go to the Machinimatrix website. They accept paypal payments too.

There are 2 values, called ease in and ease out, that define how much time in seconds the animation takes to gain full control over the involved joint(s). Even a pose made of 2 frames in total obey these settings. Depending on what type of animation format you're using (BVH or .anim), these settings are available in different places. Assuming you're using the BVH format, you can find them in the uploading window

It was late night for me, so i guess i'd need to expand on the reasoning behind it. I'm advocating for the new calculations to have more reasonable cost when uploading a mesh that is not a few triangles/impostor, in such case i would like that penalty for the generated LoDs, as i'm also advocating to have a reward for making LoDs. However ChinRey explains it very extensively above. Because you can never know where the item will be placed, and this ensures that at least a cube (12 tris) would be set in place with a projected texture. Again, the penalty i'm advocating hits the shortcut-takers, along with new LoDs costs calculations that should account for a less harsh cost on the lower LoD, as it seems LL is doing starting from Animesh project to extend over other items types. However, it might not be clear from there, the idea is to penalize by doubling the calculated LI/RenderingCost if the lowest LoD is set to zero, quadruplicate it if ALSO the Low is set to zero and octuplicate it if ALSO the Medium LoD is set to zero. Read further below in order to include the Content Type selector ("this model represents..." rollout menu) in such idea. Regardless of the permissions setting, it's less cost effective for the creator (although more convenient for LL), it creates a mess in the customers' inventory and tons of alternate assets for the same model on the servers. Indeed you answer yourself at the end of your quote, the ideal solution. Here comes the actual implementation of that Content Type selector, where one could bind a subset of rules, making it convenient to use in order to spare on assets costs AND prevent some system gaming. As it is right now, it's something that only ends up into the compressed mesh file header, with no actual use for it or consequences, if the incorrect one is used or just left as default blank. It may also disable skinning import if the content type is set to a more convenient type to game the system. So i think 4 basic types (to begin with) could be Indoor Static, Outdoor Static, Animesh and Rigged Attachment, each one with its subset of rules that get written to file -as they currently are- and used for calculation of resized objects (another prevention measure to avoid gaming the system by setting the most convenient content type to use it for other purposes, as proposed in the Animesh project to avoid the misuse of Animesh to lower costs and get a looser LoD polygon pool). Content Type can be a multiplier based on the object size. This would need an exception calculation for existing content so not to break all the assets that have never imported using this selector. As per the costs i mentioned... Indeed i NEVER spoke about monetary costs you seem so attached to for your artist standpoint of earning an income, if you read the example code it's about LI or RenderingCost AKA Avatar Complexity. Making the rendering cost 8 times higher would constrain clothing makers from the easy solution that exploits the avatar LoD switch, a calculation bug for which there is an ongoing project btw, booming the rendering cost so high that their customers would have their viewer crashing within a few minutes, resulting in complaints to the creator. Since it's all about customer demand, they will comply or find themselves orphaned of their customers. Therefore such enforcement method based on the penalties as i expanded on would result in having people to upload a single triangle, so at that point why not making a full LoD model?

Thiking about it, i would like to see something implemented that penalizes the zeroing out of LoDs, like: if (Lowest LoD == 0) { (LI |Rendering cost) *2 } if (Low LoD == 0) { (LI |Rendering cost) *4 } if (Medium LoD == 0) { (LI |Rendering cost) *8 }

And this is why i agree with CoffeeDujour about some way to penalize the shortcut takers in a way or another, as also proposed and mentioned by Elizabeth Jarvinen at the content creators meetings. I can't see how "artists" can make the comunity happy with content that breaks performance and clearly only caring of the $$$ you mention. Yes, this would also slowdown their production, because if fast production rate = crappy performance content, the platform suffers from consequences.

Thank you for your comments' relevancy and widespread technical knowledge and wisdom you deliver to all of us.

@CoffeeDujour and @Kyrah Abattoir Your points about texture reuse being dead is one of the main factors that make me advocating for a materials layering system. I read Kyrah works in Unity in her spare time, so i'm quite sure she can see its use. I don't know about CoffeeDujour but i'm prone to believe she understands this too. Those 200 MB worth of textures per house is most likely also given by the use of dedicated normals/specular material textures for each one dedicated diffuse color texture, in my opinion. Now if we could layout a whole house in one single UV map, split in pieces yet referencing same texture coordinates, a sort of lightmapping is definitely possible, provided that a material layering system can get at least one single diffuse (no normal/specular) plugged alone on the top layer for the baked lighting (if not a specific AO channel so that it also affect specularity as it happens in PBR shaders, but i'm dreaming of much so i won't claim this, considering that the last layer could "cover up" the lower layers dimming out the specularity from those). This would bring back tileable textures, material enabled, saving on a lot of baked dedicated textures and still retain the lighting.

a bit out of place comment, i think: it's a software's feature that's being talked about, and the dropping of BVH was not meant for SL, but for said software. DUH...

On a side note, now that the internal format is available, what's the use of BVH anyway? why don't you dump it altogether, since it is so lossy after upload?

#1 is true #2 the first frame of the animation seems to be triplicated and it's especially noticeable when looping #3 they work because of #2 being triplicated #4 uploader behavior in attempt to clean up the animation from excessive data, these 2 frames should trigger a rotation delta >= a specific value, dependent from animation length and FPS (the formula is unknown to me, couldn't find it in the viewer source code)

To me this sounds good and fair enough. The main problem is that people should work with what they're given and following the provided workflow, like it or not. Don't like it? No problem, go create on those other engines then. It doesn't matter if the younger artist wants an easier shortcut to earn some money, if you take it seriously as any job should be, it all boils down to expertise = proportioned payroll. A 3D generalist whose job is to model secondary assets for a game's environment will get a substantially lower pay than the main characters rigger/animator, proportioned to the level of responsibility for the main "in the user's face" content and know-how they contribute to the production. If your manager says "do this, this way" you can't simply skip the annoying/bothering/tedious steps because all you want is your payroll and your name in the credits. I know that other engines have pretty much solved a lot of these "issues", but for the example you bring up from UE4, you should also consider that upgrading every time a new version comes up means taking the big risk of previous work within the project getting broken and in need of a rework. Therefore many developers seriously ponder this chance for a long time before they blindly go to the newer shiny featured version. And this is for individual games, which SL can't compare to for the sole fact that its servers are full of content from every stage of its life that might get broken: it's thousands of assets of any kind on a marketplace (and likely in someone's inventory) from a multitude of different people, quite a lot different from a downloadable patch that replaces files in one game, limited in assets numbers and people working at its development. This latter case allows for a sanity check and working order testing, with the ability to rework and fix what's broken before the new version is shipped to the users. LL doesn't have access to such level of control over the content, and even if they would, it's no feasible task prior to an eventual new release.

No, IK controllers are overriders to help animation. Avastar provides a 2 levels IK: a targetless IK (the one you were able to use, grabbing the wrist and moving it) and the one with a target(the yellow hand pad with the "pointer" behind the elbow). This latter type of control is used to establish permanently a location where the hand (and the upper chain of joints) should be adapting the IK chain to. This needs to be enabled using the IK controllers sliders, and they're used in animation to blend from no effect to full effect; for example you may want to use it in a backflip animation, so that you can nail down the hand positions for ground contact and take advantage of your IK chain to adjust the arm chain accordingly during the rest of the body's motion. Here it is in action: From standard TPose, i moved the controller away. Increasing/decreasing the slider's value transitions to/from the original pose to the IK dependent pose. If you want to have a maniulator to rotate, here is where you can set multiple manipulators to show together: Hold down SHIFT while you left click on the marked manipulator selector in the image above, and you'll be able to move AND rotate via manipulator with both of them showing. Hope this helps

Vade Retro!

This is the result from a buggy and not reliable calculation, that is supposedly being addressed in a specific project (ARCTan). Can't be stressed enough, but lower LI and Complexity resulting from zeroing out LoDs is gaming the system and those values are NOT the real ones anyway. They do so to game the system in order to appear as "real professionals, that achieve high poly at low cost" but in reality those are more noobs than the last illiterate noob that has ever logged into SL or any other game-asset-based platform ever created. Make your LoDs, when the buggy calculations will be replaced and LoDs will begin to properly display, the "pros" will have to update or retire their items, you won't.

This is a quaternion rotation, which is best to avoid Gimbal Lock You can change the rotation type to Euler XYZ if you prefer, but remember to do that BEFORE you set keyframes in place.

oh, one more tip: If you wish to rotate more bones at a time, you can do this by switching the pivot point mode here: in conjunction with the previous tip, this will allow you to get a manipulator that is always aligned to the selected bone

You have to change the manipulation axis when selecting the wrist controller, from Global to Normal. It's available on the lower tool bar, see this pic: Also, it would be good for you to take the habit of reading the tooltips whenever they're available Cheers

To me, the problem is from the uploader itself and its assumption that Low and Lowest LoDs should be just a few triangles or, even better, an impostor which means a plane with the object image on it (again, few triangles), and every single triangle on top of that threshold is severely punished. It wouldn't even be a really big problem if the uploader wouldn't also claim the same geometry to be within the materials/geometry subsets of the previous/higher LoDs. I mean, if the the uploader would accept a different model for the two low LoDs, it would be easier and certainly more efficient/effective. However not all models can be treated this way, so a complex tree with planes as its foliage either simply shows bad LoD decay or an obvious model switch from a distance. Which is obviously frowned upon. I hope that the new Animesh LoDs thresholds would be implemented for all items types, and perhaps also allowing different models to be loaded into the low LoDs slots without the need to have them in the higher levels.

It's a long time that i don't use both Blender and Avastar, so i'm trying just to help troubleshooting. In your second picture, the left side corner shows checkboxes for weight transfers from specific body parts. So the first thing i may think you could do is to uncheck the body parts that aren't actually involved in the process: hair, head, eyes and skirt. Aside from this, i seem to remember that i had issues with the "Attach Sliders" feature when calling the Binding. At the time, i think i've solved quite a bit of issues by unchecking the option for "Attach Sliders" at first, and only after the regular binding took place, i enabled this feature. But again, it's a long time that i don't touch both softwares and things may have changed consistently in the meantime.

The evaluation done solely on land impact is a big mistake: what really should be accounted for is the triangle or vertices count. Being lower or fixed LI doesn't actually mean that they're more efficient. However, to have the most efficient sculpty, the lower lag ones, you must make sure that the sculpt maps comply to a specific number of pixels, 4096. So whatever sculpt map dimension in pixel that gives you as final result 4096 pixels is efficient (example: 64*64 pixels or 32*128 and so on down this line), if above this number, those are "the laggy ones". Note also that you can go lower than total 4096, for low detail objects a 32*32 works as well, as the total number of pixels is below 4096 (the max it should have). Anything above a total amount of 4096 pixels is wasted resource and doesn't give any higher detail

Good, let me know by quoting me (so i get notification to not miss it), if it works i'll see to output a version with properly bound avatar meshes =) Cheers!