OptimoMaximo

The meaning is a simple and aseptic reasoning and understanding of others' choices, and ultimately respecting them. My comments have come in in the past, and will keep coming, like that every time I see the all-mod fan crowd chime in with their respect-lacking motivations (nomod decreases the value blah blah type of comment). You don't find value in anything that is nomod? Fine, we all got it, time to move on. I find the continuous and repeated nudging in that direction annoying and obnoxious, with a point stated over and over that, clearly, the recipient(s) of such complaints don't give a shoot about.

I'm very glad to know that I would never get a customer such like you. How many times did I read the all-mod fans you belong to state they would pay an higher price for the mod version? Stand by your words then. In my store, not the brand I do modeling for, I sell full perms and one product in no mod and mod versions. The other things are plug ins. Indeed I don't personally get any complaints or support requests, the latter of which are limited to installation help of my plug ins only which I promptly provide, as you can read from the reviews. This doesn't mean that I can't see the reasoning behind the nomod creators, it's their call and I can understand why they do so, whether I agree with that or not. If the owner of the brand I model for would ever choose to set the products as mod and avoid HUDs, so be it, it's not my concern. I get the share for my part of the work and I don't get to deal with anything else because, as I said, I don't have the time to manage what a store takes in terms of time and efforts. I prefer to keep developing my tools and plug-ins. Please stop putting words in my mouth as if I were the one doing and defending the no mod practices. What I stated are the reasons I can see and respect, the latter of which you both, and all the all-mod fans, apparently don't have.

I never implied that I make houses. Whoever has read my comments know that I do model for a small brand to avoid having to deal with packaging, MP, HUDs and, most importantly, customers. Even though my things are being set to copy, I get occasional support request for screwed up items bought from the store I make models for although the items are linked to a prim created by the store owner. Somehow these individuals are able to inspect an item and find out who made those things instead of contacting the store owner avatar. The store owner confirms the support requests are many. And we don't sell mod items! Most of the time the screwing up happens in the HUDs... Because they're in no scripts areas and the hud doesn't work. I have one thing in my personal store that I sell as copy only and as mod copy at different price tags. Guess what? The cheaper one sells better. Useless to say that it is the copy only version. Edit to add: the mod and copy version didn't make me get support requests, no. But then, I sold 3 copies in total of that item version against 478 copies of the no mod version.

Experience. It depends a lot from what type of content you make. If you make say houses with planarly tile able textures is one account, when you make complex uv mapped item that do not use tile able textures it is another bag.

Yeah, creators need that enlightening from you. As if they (we) didn't know already. How hard is it to understand that the creator doesn't want the final user to fiddle with color, textures, their parameters, etc. The argument of "you can't think that we're so inept to ruin your creation" doesn't hold up because the majority really is build-illiterate. Selling 100 copies and then dealing with 40 support requests because the buyer screwed up the product isn't fun and it's a waste of time. Ignoring them leads to negative reviews or bad word of mouth, so there comes the choice for no mod.

The question in the OP refers to the blinking action, aka the eyelids movement. This bvh file points to the eye joints, which control the actual eyeballs, not the eyelids. Those animations are builtin and control the mesh blendshapes, the same type of data that made the hands shape change possible. Built in animation name list can be found by googling for "internal animations" and simply calling a llStopAnimation() using the wanted animation to stop's name between the parenthesis, enclosed between quotes. As noted in the mentioned wiki article though, stopping built in animation could break some behaviors in animation and is not advisable. But I don't think that this specific animation should cause any breakage.

The only way to get the texture flow seamlessly across is to 3d paint it on the model. You can do that on a variety of softwares, photoshop, Blender, Mudbox, Substance Painter. The only requirement is to have a SL avatar model to load in the application of choice.

The question in the OP is not about fitting. It's about an error that prevents the mesh from being uploaded in the first place and the rigging issues are yet to be seen, IF any are to arise at some point.

'nuff said.

Useless to waste time and efforts on this one, mine was a sermon and yours is going ignored. Let them boil in their own broth I say.

Yes, good modeling practices. First, the geometry coming from ZBrush is trash but for sculpting, it's not really meant for game assets, even the zmodeler tool set can create crappy topology. Secondly, polygroups have an organizational purpose only, for the select tool and at most hardsurface modeling in couple with the deformation tools in the tools palette when it comes to polishing. Third, dividing geometry by materials for easy texturing ends up in a pile of VRAM heavy textures when you could use better packed UVs in a single texture.

Sure, I was pointing out the reason for that. However alpha masking doesn't really work that well with such tiny and intricate patterns at these resolutions.

Well, using the server side animation calls to override the defaults would realistically make us able to use the same priorities LL set for the default animations, but it seems that all AO's still use the old method llstartAnimation. Using the default priorities would get us one more priority slot for use

No, but the transparent parts need a glossiness of zero or that would look like transparent glass otherwise.

Your UVs overlap the udim tile boundaries. Leave some space (like 5 pixels or so) between the UV shell border and the UV tile border. Also make sure to set padding accordingly when baking

The avatar itself is phantom, no physics at all. There is what is commonly known as character controller, a box or capsule, that envelops the avatar and that is the object subject to the physics and responsible for the whole agent movement in 3d space. Their complete name is collision volume bones, for two reasons: Volume refers to the fact that their scale represents the volume of the skinned mesh section those bones control the shape of. Collision refers, instead, to the broken animation functionality known as IK (inverse kinematics) which, theoretically, would enable these bones to be used as collision detectors and ik chain target for such effect. Currently this feature is broken and works only with the default animations.

You're missing the fact that you can't get anything like custom skeletons, it's still the same base avatar skeleton as your regular user avatar, just flagged as a different class of object that enables the animesh feature. Indeed if you turn off the animesh flag and wear the animesh, it starts deforming along with your avatar. When turning it on and attaching it to yourself, what you're basically doing is to attach a second avatar to your main one.

Because attachment points like in the regular avatar aren't supported at this time.

@GManBYou can go to the preferences, settings section, and set Z axis up. It's a permanent setting until you switch it back.

The last one called by the script is the one that runs, in that case Stands usually get a priority 3, walks and runs a priority 4. The only way to override other animations is to set your anim at a higher priority than those intended to be overridden. This is an option you can set during the upload process of bvh file animations. However, the other animation file format,.anim the native internal format if SL, gives you the opportunity to set priorities up to 6. The only tools providing such export are Avastar for Blender, MyAniMATE for Maya and Marionette for 3dsMax.

No, autodesk software have options for what fbx version to use to export. In Maya, it's right there on the right hand side panel of the export window and in the export options too. I'm sure also 3dsmax has these options, although I don't know where that options panel may be buried.

Not really, it's a Vedic symbol that the hamsa was derived from. See the hand with an eye in the palm in many depictions of Shiva, Ganapati/Ganesh, Brahma and the other countless gods in the Hinduism.

Probably you don't realise the implied connection to Vedic symbology used across all of Second Life, starting from the word Avatar, the grids names Aditi and Agni (and all other closed test grids we don't get to even see the names of, that at least existed years ago), the whole concept of a being that controls an unknowing body to navigate a 3d world and such.

Don't let the SL term confuse you. In 3d rendering, diffuse is the color of the light that bounces off a surface, while the color is the actual base of the material color Collada handles texture in two modes, relative path and absolute path, so while some apps let the user set the mode upon export, some other don't which defaults to relative. SL uploader wants the absolute path instead, so here is the trick that worked for me with old version of Blender without the aid from avastar: Assign your baked texture to the material color Export the dae file in the same folder as the assigned texture. Hopefully this still works

Without seeing the model itself or anyway more info about your model, it's very difficult to get a lead about what it might be. The error you're getting is very common with high poly multimaterial assets