Jump to content

Kitsune Shan

Resident
  • Posts

    373
  • Joined

  • Last visited

Posts posted by Kitsune Shan

  1. Nice to see people that know what they talk about. I have said this same thing a lot of times. Is not that hard and isnt content breaker to make a new avatar. Just LL isnt that eager to changes, nothing new. But well, maybe someday, who knows :).

    Going back to the subject, I have been very busy to test but, does Bento already support proper BVH animations rather than having to rely on anim files now that animated positions its a thing? Anyone tried?

    • Like 1
  2. Those bones are static which means that, if they dont move, they are exactly the same as mWhirst bones. The only difference right now is that, by default, the automatic weighting from softwares take into account the proximity and size of bones. But for SL we have to better take into account the joint position and forget totally that there is a bone. You should be able to get the exact same result using mWhirst bones (or HAND) instead of the extra added. Of course, you wont get good results by simply adding the bones there and thats kinda expected. Just paint the weights manually to fix those issues, it shouldnt be too complicated. Pose the model into the problematic pose and start painting. The main base its to think on joints and not bones. There are joints, bones are irrelevant as elements because as long as you keep adding weights to certain bone, you can extend or shrink that bone. Its kinda a bit abstract to explain but the idea of bones holding the mesh its wrong and just a mere guide to make rigging, skinning and animating a bit more "visual". What we really have its just certain points for rotations called joints. 

    • Like 2
  3. That would be even worse. That format isnt so widely supported.

    Even the actual BVH isnt easy to find on all applications. It would be a way easier to get animations through DAE or even FBX files since you can save in those formats pretty easy and even convert between them without any issue. Aside of that, its the most widely used method for animations on games engines.

  4. Thats exactly what I said.

    Only when using fitted mesh is when things starts to get bad. Which is what happens when you try to rig to whatever mesh body out there. I cant really show or provide an example. Those bodies arent shareable. Whoever is used to rig a bit may know perfectly what  meant. I dont think its something so complex to understand to even provide examples about it. The main thing is that actually you cant make all perfect that you want rigs due this limitation. Anyway, its pretty clear that they wont change that. Facial bones will more likely enter in the same problem. We may have to use low quality rig in order to be able to rig faces. This will lead to creepy and low quality expressions. If collissions bones could behave like they should, this wouldnt even be necessary but thats not the case and we may have to deal with it till at some point (which I doubt) LL decides to give it a try.

     

    As for the number of bones, I would rather add one more bone to ears and tongue rather than two tails. While I can see its use (no bone is useless), I dont see too much situations to use them even more if to have them we have to renounce to others. If we could have all of them I am all for it, but to have two tails in exchange of less others features isnt something so great. Its quite the same for the 3 roots bones for face bones. We could go for only one and save the others bones for something more useful. I dont even see any real usage to have 3 different roots bones there. One could be use for a head and use the actual head as a neck.

    Again, I dont mind which bones could be added if we could simply choose all. But having to choose, we should go to priority use.

  5. Hehe, Im sorry but the theory doesnt work here.

    I can see why you think that but its very far from reality.

    As I mentioned before, Im professional rigger (I would better use skinner as rig is something totally different but we know how this workwithin SL lol) and been working for Blueberry since more than a year. I have also worked for others popular brands like Reign, Addams and others. I have even made the official dev kit for Maitreya Lara so I can tell you pretty well how the limit affects the rigs.

    Lets first state something. Yes, "technically" 4 is a good value. The problem comes from avatars and fitted mesh. Fitted mesh doesnt really act like it should when you move sliders. If you increase, lets say, legs witdh certain amount, you get a totally different value making use of only fitted mesh bones. This situation forced mesh body creators to naively make use of both, fitted and normal bones, to achieve good deformation results.

    Unfortunately, this leads to too much weights everytime to want to rig something to those meshes. While this isnt really an issue from LL, its a reality that we cant ask to those creators to reduce the weights of those bodies that already are top on sales. So we need a solution to this, even more if you plan to rig faces as 4 is really too short limit.

    If you want an example, try to draw this in your mind, then you will see it clearly.

    Imagine you try to rig a skirt for a mesh body. Its legs uses 3 to 4 bones each (L_UPPER_LEG. PELVIS, mHipLeft, mPelvis, BELLY,etc..) then try to smooth those weights so the skirt acts like a skirt instead of like a glitched shorts and you will see how you need a MINIMUM of 6 bones per vertex.

    We really need to introduce this change and now is the best oportunity before people start to realize and complain about it once Bento is realeased since you will see even more openly this scenario when rigging faces.

    • Like 2
  6. Are you guys sure that you want the facial bones parented to skull rather than head bone?

    Remember that mSkull bone moves upward with some sliders. I dont think people would want their eyes, mouth and such move upward while the rest of head remains still lol. I think that just having another bone that could holds the facial bones just as mHead children could be the best. It could also work as extension for neck while not breaking anything else.

    • Like 1
  7. Could the preview window show the animations after the performing the optimization?

    Would be nice to see how the animations will really look once uploaded. Could help to get a real idea about if our animations are really well done or not.

    For example, alerting users about framerate may not be a bad idea but take into account that this optimization doesnt really depends on framerate itself but the whole file size. So an animation could work perfectly at 30fps as long as isnt too long.

  8. My comments are all toward Bento project.

    I wouldnt do such comments if people like me could upload animations in a proper format rather than rely on hacks and scripts to be able to export to anim format.

    So far Im totally stuck if I cant use bones translations to test all the Bento features. A good start, now that translations are possible, could be to open at least BVH files so translations arent locked anymore. Then Im sure that the debate about which software to use to be able to do such task could end.

  9. I have been using 3D Max for too much time to do the switch, plus I dont feel I should simply because SL uses a propietary animation format. I have played with it, did things, isnt too hard. But I can simply work thousand times faster on a software that I know completely rather than always have to search and learn how to do something that I already knew in Max. I dont even have the time to learn a whole new 3D software and if I had to for whatever reasson I probably would choose a different one :P.

  10. I think you didnt got what I meant.

    What I gave you with that little math form is to scale translations without having to use bone scale :).

    In others words, it would take joints offset into account to scale how much translation would move meaning that smaller avatars would move less while bigger avatars would move more. The animation system itself for supported anim or bvh files wouldnt need to change at all, just how SL handles animations. We may still upload animations in bothways, original as absolute or new as relative because certain situations wouldnt require relatives animations. Take intoa ccount that relatives animations only aims to give compatibility between different sizes humanoid avatars and not to something different like quadrupeds. But the good thing is that it would work even on avatars that uses joints offsets for some deformations as long as they are humanoid like. This isnt really a big issue about updating itself because all new avatars made with bento will also look wrong on outdated viewers. So having to change some details on animations wouldnt meant a big deal knowing that everything may have to change anyway due bento bones. Have you looked a bento avatar on a non bento viewer? It doesnt looks just non rigged but totally deformed.

     

    And to Gaia, thanks for taking such task into consideration. I have no idea how avastar animation exporter works but I guess it would mean just export based on bone naming. This would require to meet certain criteria like proper size and orientation but once users gets used to it, things should be easy enough. Ill try to make some dummy avatar with some animations on it and give you the file so you can test how to make it work. Thanks :).

  11. Free avastar would indeed help but I really wouldn't mind paying for it to be honest. 

    I have once played with it but couldn't do too much as I am 3d max user. The main problem I found on avastar is that I wasn't able to import my own avatar as dae or FBX and export anim files. Only making an avastar entity allowed me to do such task. I know it may be possible to retarget and export but it makes a bit tedious something that should be easier. Could be possible an animation exporter that allows you to export whatever animated mesh you import? Because then people that uses others softwares for modelling and animation could simply use avastar as exporting animations softwares. 

    It seems that some people misunderstood what I meant by using blender for animations. I never said that is bad or that it lacks features for said task. But it's very clear that isn't an easy task to animate there. Let's say that isn't so user friendly. For example, knowing 3d max, I can pretty much manage any software like Maya and cinema without too much hassle but blender is always a different whole thing. 

    The main objective with dae animations support would be to make it easier and open to everyone and every software out there. Dae files, as you know, are simple xml files. To do an anim conversion internally from a dae skeleton shouldn't be an issue. Who would know better anim files than LL? An alternative could be bvh files but that's the thing. All key frames are stored, this have good and bad things. Bad things is how file size quickly increase and SL have a limit that, despite of being doubled recently, it will not be that big once you try to upload 200 bones animations with translations and rotations. I'm afraid that SL optimization system may kill too much quality. It have the good side of having fidelity but since it's killed in the optimization process, I'm not sure if compensates. Dae animations could be done virtually on every software, or even exported as FBX, reimported to a different software and exported again. Bvh files are OK, but not every software exports in such format. 

    Again I would like to do special emphasis, could every other software user export an animated model as FBX or dae and export the files from avastar as anim? It wouldn't fix the whole problem but it could be something really useful. If this is possible, my apologies but I never found an easy way for such task. 

  12. Well I have no idea how an internal animation really work but seeing that SL plays them without taking into account the fps that SL is running at the moment, it means that it interpolate every frame so, in theory, you shouldn't need every frame to be store because if you play a 30fps animation while playing at 60, it would be notable right? That's something that only LL can tell us. Anyway we are changing things so is a good opportunity to optimize some aspects about that. As long as it supports dae animations, I don't really mind how SL would store those animations, if optimized or by brute force with every single key frame.

  13. I wonder if this solution for scaling would be possible.

    Im not programmer so all I can do is just to write this basic math that should do the trick. Would be nice if someone more aknowledge look at this solution and find if is ok or not.

    Cant the translation be calculated through the initial parent bone offset?

    Lets say that from mTorso to mPelvis there is a distance of 0.084m on Z axis, this would be a value of 1.0.
    If an animation move mTorso forward two meters it would be multiplied by the result of the new offset divided by the default offset (the default offset is calculated on the joints offset only once and not after being moved by an animation).

    I guess it could look like something like this:

    Final Translation = AnimationOffset * (NewParentOffset / DefaultParentOffset)

     

    -For example, if you animate the mTorso bone forward 2 meters:

    On the default avatar would be calculated like this:

    2m * (0.084m / 0.084m) = 2m * 1.0 = 2m

    The bone would move 2 meters because the bone offset is the same as the default. But if instead we do the same on an avatar that its half size and with a bone parent offset of 0.042m instead of the default 0.084 it should move half:

    2m * (0.042m / 0.084m) = 2m * 0.5 = 1m

    The bone would move what it should. This should apply per axis of course but right now I see it working. But we must keep something very important in mind. Animations would have to be uploaded as relative or absolute through some kind of checkbox because, if you make a custom avatar that needs custom animations, these doesnt need and either shouldnt use any kind of calculation. The problem here is that we need a default offset to compare with and we can only get the default avatar unless there is any way to specify those values directly through the animation first frame or such. Anyway, I wouldnt see this as an issue because if you upload an animation to be relative, you should know that you have to use the default avatar size. This would only primarily fix the issue with making AOs on humanoid avatars that requires bones translations but should be also compatible with different avatars sizes. This wouldnt work on custom avatars that requires custom animations to work. It shouldnt be necessary at all because lets say a quadruped wouldnt need to share animations with others quadrupeds. It would still be possible as long as only rotations are used.

    My apologies if this have no sense, Im not programmer and I just wrote this quickly as a base to understand what I meant. In now way is intented to be a perfect math form or anything.

  14. "Re-enabling" kinda means that it will work like in the old way with just anim files? Because if thats the case, we cant hardy test anything considering that those animations can be only made with avastar and blender. Any chances of importing animations through DAE? I would like to see FBX support but we already have DAE support which can contain the animated skeleton and which SL could parse into SL animations. Otherwise, animations will be very limited to users considering that blender isnt by far a good animation software at all. And, while BVH support isnt bad, lets not forget that it was an animation format designed mainly for motion capture. Having DAE files support for animations would be really great. It would be very easy to import any type of animation file and export as DAE within all kind of softwares. Also, something to keep in mind, DAE can save individual keyframes meaning that only those keyframes that have been animated would contain info saving a lot of data (ie. you would just get info of the keyframe that have been moved/rotated and the rest would be left blank instead of saving a keyframe on every single frame of the animation). We could get better quality animations in less footprint.

  15. No you cant. You couldnt actually upload enough quality animations. SL have a very strict limit on animations upload and facial animations itself requires a huge bunch of data. Multiply that by 3 adding bones chain and your files will be so big with simple animations that you wont be able to upload to SL without screwing up the whole animation. Unless you want your avatar to look like a robot, this isnt the best method. Not to mention the performannce impact. Bones chains is old and outdated. We are trying to bring SL forward, not back.

  16. You may agree that giving to users some good explanation regarding the issues of using bones translation would be very helpful to identify the problem and find possible solutions. If, for example, all they can say is just "no" without a minimal explanation then people gets frustrated and confused.

    Basically, you cant give to everyone a feature and then restrict the most important part of that feature. Its obvious that implementing translations is not impossible. Its already in SL, it works and its being used by several users. I think it works pretty well considering it was never meant to work nor it was an official feature either.

    I think comunication its very important here. Just in the same way as they ask us to understand why translations is so important, they have to correspond us and tell us why translations could be a bad idea otherwise none of us will understand each other.

    Guessing problems, whatever may be an issue can surely be avoided or minimized. Not everything have to be "translations yes or not". We could also add them to certain bones only or maybe to a certain degree and limits to avoid those possible problems. I still think that the best idea is to give users freedom about it rather than limits.

  17. I think people are missing one HUGE important downside that makes the "only rotation lets use bones chain" idea totally useless.

    Do anyone here uploads animations? If you do, you may have found yourself  into hard problems due SL compression of animations.

    SL have the bad habit of "optimizing" animations size. To achieve this, once the animation is uploaded, some frames with sligthly no difference on rotations are totally deleted. If you uploaded animations before, Im sure that your first thoughs would be like "why my animation doesnt look like on my 3D app?". You can actually see this on certain AOs. Once you wear one and the AO have some pelvis movement (bending over and such) you will most likely see your legs shaking. We could think on this like some kind of "jpeg" compression translated to animations. Even after the increase on size of animations files, this problem still persis. Some workarounds is to reduce the fps of the animation to something very slow. Since SL interpolates frames, isnt a big issue asides of missing some details on movements.

    Ok now think on that issue translated to the new bones. Take into account that bones have increased to, how much? 3 or 4 times the old ones? Add to that some bones chains for the supossed facial animations. Just the face bones should be increased by 3. Now, with all that try to make an animation. You will then hit a big wall when your animations looks nothing like the ones tried to make, when your face starts to get some muscle spasms here and there and when the file size limits your animations to very short clips.

    Adding bones chains wouldnt just decrease performance, it would decrease animations quality. Unless these animations file size gets increased by the same amount of bones number.

    By the way, I am not sure why everyone is looking at other side regarding the problem with joint offset. As I explained before, joint offset would be required on every mesh head made for the new bones. Meaning that every single avatar would be deformed back to the default size. Im not really sure wether people just dont understand the concept, if my explanation is confusing or if there is any other reasson but this issue would be a total content breaker unless we have bones translations to avoid that.

    Leaving the bones translations subject, I would like to recall on the bone per vertex limit issue.
    We already strugle at time to rig using fitted mesh bones in combination with default ones. Certain parts are surrounded by more than 5 bones while the limit is 4. This gives you distortions on skinned meshes and often puts you on the choice of having to disccard some necessary bones simply because you cant add more than 4. If the limit is really tight already, try to imagine if you add the new bento bones. Think when you will try to make a smooth facial skinning but you cant use more than 4 bones per group so you have to discard essential facial bones for an optimal animation. We need a limit of a minimum of 6 bones per vertex. I am not programmer so I am not sure wether tis can get scaled to 6 or if have to be directly raised to 8 like most games engines. But the fact is that we really need to be able to rig to more bones per vertex if we want to use the new bones, fitted and old ones properly.

    • Like 2
  18. That rig is done in Maya and that little window its the rig itself. For face animations you always needs a rig for easy manipulation of bones. Usually rig is done with elements inside of viewport but this one is kinda more advanced using scripting.

    Now, as for the video itself, that rig its totally possible in SL. Lets take few things into account tho. One thing is a rig, another different is the level of realism that it canachieved. An exact same rig can be used in SL as long as it fits into the number of bones. The one on video surely have more bones than SL Bento but thats not really an issue at time of having a good rig. Doing a rig like that one is very hard because it uses lot of controls, but as I said, the base which are bones are the same. What some people dont know is the realism on that rig also comes from blending normal and displacement maps. When polygons stretch or expand they change normal maps to make it look like its getting wrinkes but it doesnt. Whoever tell you that this isnt realistic or that its bad to compare with SL, its wrong. Facial realism isnt limited by the platform but by the creative side. Basically I just meant that SL can be very realistic on facial animations. It wont have blending maps but animation can be 100% realistic. A different thing is to achieve that for the average user, but the tools and possibilities are there. I think isnt a bad example and anyway that video were shown as "inspirational".

     

    Going back to the subject, lets see in which state is bone translation right now and which are those problems that seems to make it so hard to get it done properly.


  19. How long have you been playing SL?

    At this point, if youe ven reached the forum, you should know that where people spend more money and time is dressing, changing and decoratin their avatar hence why Bento is here. We cant focus on inworld tools because whatever tool you try to make for SL inworld it will always lack on or another feature and people will end doing things outside. SL is just so advanced that people wont rely on tools that gives worst results than using a 3D app out of it. If someone is mad at this project just because have no way or know how to use it, they can simply start learning like everyone does. We cant live in the past just because people lacks the knowledge to move forward. This reminds me to those that blame meshes just because they have no idea how to do them.

×
×
  • Create New...