Jump to content

Kitsune Shan

Resident
  • Posts

    367
  • Joined

  • Last visited

Everything posted by Kitsune Shan

  1. You dont need extra bones for that. All you need its to rig the hand properly using mWhrist or HAND bones. Those extra bones are totally static so there is no sense on having bones that replicates the movement of HAND/mWhirst.
  2. Whats the difference between 1 and 3? Arent they both just 3 more bones acting as root for face?
  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. Looks promising. Have you made any progress about importing a custom animated avatar on DAE or FBX and make it avastar compatible for animation export? Or have been BVH unlocked for that task already?
  5. 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.
  6. 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.
  7. I think it could be easier to simply add an extra bone after mHead where all the faces bones could be attached. Then mHead could be used as extra neck bone. That extra bone would be irrelevant to most people but helpful for custom avatars
  8. 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.
  9. 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.
  10. 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.
  11. 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 .
  12. 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 .
  13. 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.
  14. 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.
  15. 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.
  16. "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.
  17. One of the hugest problems Im seeing in this threat is that people trend to see good and bad side of different methods. But there are already some problems that seems to make a totally misstake rotation as alternative unless we change several others things and limits in SL.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. That would be very problematic. There's a lot of content already like hairs which uses the skull bone because it does allow some adjustments. Having face bones rigged to there would lead to incompatibility with several hairs. Rather get two bones on neck instead.
  24. Thats quite far from the project objetive. It surely would be nice, but Bento is about extra bones and what you are asking for is morphers support in SL. I dont think we will see morphers support for any time soon. They dont even seem able to implement translation properly yet something like morphers may be out of their capabilities.
  25. Lets be realistic on the subject. SL have to be adapted to certain standards but you cant "break" those standards to make something viable when to start its totally wrong. Changing how animations should work just so people that does an AO using bones translations can still use their AOs its really pointless. If they choose to use bones translations for parts that shouldnt use, its something that should rely on their side and responsability. I dont think that SL should accomodate to wrong workarounds. There is no point on using bones translations asides of facial bones unless you are making a special AO for a special avatar. In that case, the animations dont need to carry over to different avatars nor it should anyway. So we are discussing here why animations have to be compatible with everything when in the real world they never are. When you work on game characters and develop animations, you can retarged and adapt them inside of your 3D software. You can reuse them adapting them and they work perfectly. But thats it, they are being adapted again. Unless you use certain kind of locomotions and inverse kinematics in SL, you cant really expect animations to work on every scenario and I dont think that LL is aiming at that. Again, it doesnt matter how animations scales properly, you wont be able to use facial expressions on different heads unless they were done to work on pair with them. Every mesh head will require different joints offset, different degrees of movement. There is no way that these animations will work in the same way on a different head. Its really something trivial, it could work just by coincidence or if bones offset as well as mesh head itself doesnt changes that much but in most case thats not the case. The example of different avatars size was given. I dont see why an AO developed for a little pixie avatar should work on a huge orc avatar. It wasnt made with that purpose, they are custom avatars which requires custom animations and if translations were used its because it was needed for certain actions that only the avatar for which were made will use. As mentioned before, if you make just a general AO and you shouldnt use translations but you do, is no one else fault but yours. Not because someone may not know something it doesnt meant that should be implemented. I myself have bough certain things in SL, clothing, that for no reasson uses joints offset and broke my avatar making them totally useless. These pieces didnt require that, but surely the creator didnt know. Should have LL remove that option because someone doesnt know how to do use of it? Surely not... If necessary, when uploading animations a checkbox for adding translation could be added to prevent those less aknowledge to upload something that could break certain things. But still, if someone makes something "wrong" and mess an AO, its on their side to fix and reupload it. Adding enough documentation surely will also help people to understand everything and how new things works. BTW if someone remember when OH are inworld and at which time, woul be glad if tell me. I would like to be on the next meeting.
×
×
  • Create New...