Jump to content

OptimoMaximo

Resident
  • Content Count

    989
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by OptimoMaximo

  1. WHA? That way you don't have the hair double sided, and nobody wants game grade optimized content :sarcasm:
  2. Go to mayastar menu, myanimate LT and click on generate animation skeleton, choose yes if you have a fitted mesh avatar in the scene, then anim when asked to choose animation format and finally the rig type, HIK or no rig. After these steps you're ready to animate. This is Not the same as going to the animation section of the avatar menu and choosing an animation template. Those are for bvh exports and only on default avatars.
  3. This means that an attribute on the export skeleton is missing, and both the skeleton and the attribute are created by the script when generating the animation skeleton. So you're either attempting to export the animation from the skeleton you're rigging to, or have deleted one of the generated skeletons, namely the one called hip which is the one used for export sampling, or you haven't generated the skeleton with myanimate and using the animation set up provided with mayastar. There is no way a script "forgets" to do something while completing all the other tasks. I suggest you to go through the instructional videos I've put up on yt first. Rigging and animation assumptions in SL assets differ quite a lot from one another and the animation process requires those generated skeletons, setup in a certain way for bvh or for anim exports.
  4. From the look of things, it appears to me that you're not using the mSpine bento family of joints in your rig. Are those joints still in the skeleton even though not weighted? I'd make sure they are no longer part of the skeleton reparenting mChest to mTorso and this latter to mPelvis. For the UV map and your screens hot inworld, it seems that each bone has its own texture, but that most likely goes beyond the limit of 8 materials, so that may be a cause. As a final note, I wouldn't trust Maya Collada exporter. Not only it takes ages to complete an export, at least on my machine and my type of content, but it's unreliable. The best method is to export using fbx, version 2011, and convert it to Collada using the free fbx converter software (2013.3 is the latest version)
  5. I believe you made that object out of a curve and the surface is a nurb surface, which is a parametric object, not a mesh. You can go to the object menu and do a convertion to mesh and export again
  6. ... Sansar's shut down event. Completed the sentence for you, no need to thank me LOL
  7. Then it may be that you have multiple UV sets, and only the first one, map1, is taken in consideration by the uploader. In this case, copy the uv from the additional set over to map1 and delete non deformer history. About the weights, that behavior may happen if you don't run skin, edit influences, remove unused influences and / or if you don't limit influences to 4 vertices per joint. This latter can be set in the skincluster node (needing a re-check of all weights) or upon binding in the options windows. Also make sure to turn on the maintain max influences checkbox.
  8. True, but for the quick buck it is what most try to do and their customers grew used to sort of expect that from every creator
  9. Regarding the UVs not coming through as expected, what may have happened is that you did not delete history after mapping was done and before Rigging was started. In such case, exporting the mesh with all of those construction history nodes gives out a broken UV map. To fix it you can use edit menu, delete by type, delete non deformer history.
  10. As far as i know, animation export works just fine (i did export a set of animations for an avatar just a couple of weeks ago). But i'm talking about the MyAniMATE integration, it's ages by now that i don't use the BVH setup and export, so i can't really tell about it. So, just to clarify a bit on the process: you get your avatar from Mayastar in the scene. You can rig whatever you like to it. When ready to animate, you go to the Mayastar menu and choose MyAniMATE LT. It's the LITE version of my more extensive plug in MyAniMATE, but the export routine is basically the same (except that for now it can't export attachment points animations). From the window you get, choose "generate animation skeleton", my scripts will do what necessary and ask you what format you want to export (Bvh or .anim). I usually choose .anim, as the main intent for me in writing this plug in was to be able to export .anim format animations. At this point, you're given the option whether you want a HumanIK rig, or no rig, since you're doing just the ears it doesn't really matter, with the no rig option you would animate the ear joints the same way you would if you chose a HIK rig. Only then, you'll be able to export working animations. Here is the video i did time ago about how to set up your character for animation. You can skip the part where I manually assign the HIK definition because in the meantime iCathy and I have automated the process and it's no longer necessary
  11. Also, as Alyona stated above, the in built animations already have priorities, like walk and run have p3, stands p2 and sits p3, so in order to override them you can't simply make an animation at same priority, because in such case, last one triggered is the one that plays visually on the avatar and the other stays in background, never to be seen until the one visibly animating your avatar stops. Most of these issues can be avoided if animation overrides would get an update to use the server-side animation override functions. There will still be some issues for which some built in animations play for a fraction of a second, like sit on ground, but it's already better and at least an AO can establish a set of base animations that can nicely play with other animations in a sequence from the same creator i.e. A list of different stand animations
  12. Unfortunately, they're strictly tied together: until there's no widespread use of the newer AO related functions, those issues I listed above are still to occur and the solution to that is the current priority habit.
  13. Unless it's for rendering, your current setup won't let you export any animation that would work for SL. Anyway... I'm using 2019 as well, but I'm not having any of these issues. However, someone else I know is having a similar set of issues on this version, but so far I couldn't reproduce any of them. The only difference is in the OS, this person is on Mac. There might be some settings in the manipulators settings that cause this behavior, but the other person in question is having trouble with running the built in animations in MayaStar, so I'm even more puzzled now as to what it could be.
  14. Did you ever try to make a walk or run animation at priority 3? The default animation kicks in every now and then, more so when you hit something, like a step, on your path. The same goes with stands, should be priority 2 but if you make yours the same priority, the default animations still take over when they are triggered. You'd say that there are functions in LSL to set the new animations server-side, but let's face a sad reality: major AO makers use the free, antiquated ZHAO-II with a customized hud, and that still uses llPlayAnimation. They've just continued on their habit with the excuse that llSetAnimationOverride only allows 1 animation per avatar state, when it's really easy to make an efficient use of it. So before grunting against upload bad practices, we should be growling against the procrastinated adoption of new functionalities... Only after that, bad upload practices can be grunted against, imo
  15. You should make your animation on the collars, shoulders, forearms and hands only. Do not include any other joint. Priority 4 is the max priority an animation can be uploaded at, when using bvh file format. Depending on the AO creator, walks can be priority 3 or 4, but it's most likely to be 4 in the majority of walk animation.
  16. Both Maya and 3dsmax use Arnold that is a pbr renderer and it's supported with specific texture export by both designer and painter, so you get what you see in those 3d apps and bakes are extremely high fidelity to what the original material looked like. Sure enough, to convert those materials to a SL high fidelity counterpart, the provided preset for SL in substance painter is not enough and it's pretty ridiculous, but it is workable.
  17. That is the difference. Maya at least outputs non unit quaternions when the function is called, then you explicitly apply a.normalize() function on the result, exactly for these types of applications. You can therefore extrapolate the intended behavior: it all gets scaled proportionally so that multiple turn around can be encoded. But I agree with you that this is going off topic 🙂
  18. This shows your lack of understanding. The first situation you refer, the scar with pores added for an alleged normal blending, is only possible using layer blending like in photoshop, thing that BoM doesn't do on the diffuse, so I can't see why that should happen for the normal. The second case is even more ignorant, as you yourself state that the alpha channel that should be used comes from the diffuse, which can, of course, have a blending alpha edge, making the transition smooth from a surface to another, while you attempt to make it look like it would be a harshly cut out texture. Sure you can do so, but nobody would finalize that. For the rest of your intervention... Sheesh, I'm done with your utter BS.
  19. Agaaaaaaaiiiiinnnnn, the point is that CLOTHING IS NOT THE ONLY TYPE OF TEXTURE THAT THE BAKING SERVICE IS MEANT TO ADDRESS!!!!!!!! There's no worse deaf than who doesn't want to hear. I'm outta here.
  20. Or maybe add them to the package in order to get something to link, no mod, to the demo so it actually stays a demo without floating circles or boxes like other mesh bodies have? At that point use them to take a picture so that the adult bits stay covered and the listing can appear in general category. As you say, why go through an unnecessary 400% more work to make them texture too? You should be glad to have me as a project manager, because at least I know where more labor resources NEED to be deployed and where not.
  21. And again, without quoting myself from this very same page, as I said that's not something a development team worth such name can afford to think as, narrow and closed. When implementing any features, the overall working order is the thing that takes priority, and only then what's most popular takes the final efforts, not the reverse. Neglecting the fact that onion layers have been reintroduced because of the missing functionalities that BoM should had have from the get go, because as it is, it is a downgrade: it dumps years of avatar customization development making use of materials, the avatar appearance customers were used to is gone, so, once again, what's the point? 5 years ago you give the users materials to get enhanced detailing through textures instead of polygons, struggled to see the materials system adoption to enhance content, and then you withdraw it because of performance issues, not caused by materials theirselves, rather by workarounds to implement them in lack of a built in system, releasing a half functional feature dragged back to life from the old gen system, basically unvaried, just partially extended with additional channels that don't even work on their entirety? If in your mind it's right that things work so, I'm grateful that you're not a developer and, if you are, I'm even more grateful that I don't own any of your software.
  22. Hhhhmmmm... Nope. As I see it, it's all belonging to the same problem: onion layers, slices and excessive textures. The excess of textures is going to stay, along with a lesser number of onion layers, still bad, and all of the slices we had before, bad again. All BoM did was introduce a system where the excess of polygons was partially reduced and the same for the excess of textures, so appliers are to remain, meanwhile some degree of customization was removed with wearables being either no-mod, or requiring the user work to modify (see color changes in tattoos). I would gladly trade off this way, like in the old days when final customization was normally handled by the end user as a common practice, if BoM were to handle all materials and alpha masking needs from the get go, effectively dumping onion layers and slices in the sewers, were they belong. If BoM started like that, then we could talk about polygons, assets and texture memory load reduction. As it stands, it just skims some of the problems on the surface, so what's the point?
  23. Cool. But where is your request for help? what is/are the issue(s) that prevent you from progressing? Expanding a little more on the topic may prove helpful in finding someone willing to help you with the process. As it stands, it's just a statement and there's no clue as to how anyone can assist.
  24. hhhmmm..nope. I'm sorry but i have to disagree. The reason for 3D packages to default to euler angles is that there's no implied normalization taking place. When transposed in SL via scripting, that's certainly an implemented limitation, but animations do not go through those processes. Sure, the uploader converter may fail in being precise because it performs a few tasks before data conversion to the internal format and then it "cleans up" such data to output a lighter file (i know this well because i wrote a .anim exporter for Maya, and i intently read through the viewer's python data handler that performs the translation from bvh to .anim to sort out issues i had in my script). But let's face it, the now-a-days main 3D softwares used in SL all support .anim, so aside from old-school users still using BVH for who-knows what reason, bvh is practically dead (unless it's a mean for animation exchange or import for retargeting purposes, although for the latter a FBX file performs just better, although bigger in size for sure). However, .anim format has a specific rotation encoding that actually allows a LOT of complete 360 degrees rotations stacked on top of one another (i never tested the limit, truth be said), because it's not a pure normalized quaternion being written , it's normalized, conjugated (or negated, but i found conjugation gave out better results) and then translated into a integer range between 0 and 65535 (a 2 bytes allocation integer) before it gets to be written to file (each channel would be a double data type, 64 bits, or a float at 32 bits, depending on the 3D app and/or on the spcific function being called for the sampling, that instead needs to be 6 bytes, 2bytes per channel, and the fourth, the W, being omitted using a workaround called quaternion conjugation, which allows a safe reconstruction of the W term at run time, resulting in the need to write only x,y and z components from the calculated quaternion). Therefore, the problem definitely is in the program running the export, the 3D app is responsible only for pullling out a quaternion rotation but the problem is not there, it's in how the translation to the LL encoded value was done.
×
×
  • Create New...