Project Bento Feedback Thread

[Theresa Tennyson]

---

Mrsbellasteel wrote:

im curious to know after hearing many people say one thing and another alot of people have spent lots of money in sl With updating avis ect are the items we have bought going to be incorperated into bento? rolling inventory over to this new viewer?

---

Everything you have now will behave exactly the way it does now. There will be no need to "roll over" inventory - it'll be just be the same as it always was. Everything new in the Bento viewers is an addition to what's already around.

[Medhue Simoni]

---

Vistanimations wrote:

Awesome,

i will try in avastar!

---

Matrice, of the Machinimatrix team, said today that the retargeting system with the new bones still needs a little work, and it might be best to wait until the next version.

[Vistanimations]

Yes, we've seen,

we try to import a skeleton with fingers animations.

When we make the retargeting without fingers to the extended avastar skeleton all works perfectly, but if we retarget full body skeleton including the fingers it is deformed

I included a screenshoots, the first one is a retargeting without the fingers and the second one is with the fingers.

Also we tried with an old skeleton updated, and don't work at all.

 

we hope it is solved soon!!!

 



 

[Polymath Snuggler]

Vir ~ the more I think about this particular feature the more important it starts to become.

For example : I strongly advocated that the mHindLeg bones scale with the front ones ~ otherwise they'd be rather useless as quadruped bones.  I still stand by that ~ Primary use case should always come first.

 

However~~ if this scale lock feature is implemented on a mesh-by-mesh basis it would make the mHindLegs the most ideal go-to bones for people who are striving to create animated shoulder pets as they are the least likely to be in use by other attachments ~etc etc ~ in which case their slider control would be annoying at best, a show-stopper ( for their animated shoulder pet project ) at worst.

The locking feature definitely will contribute to the overall diversity of things that can be created with Bento.

[Medhue Simoni]

 



 

So, I took the large wolf out to the London City bday bash.

 

Here's him riding a motorcycle. lol

 



[Tornleaf]

Lol London woof.

 

Finally got around to roughing out some wings. Find myself wanting for an extra joint in the wing tip, but I really needed another joint between the shoulder and the elbow, and I wanted the fan bone to be at the wrist. Little stiff, but maybe I can bend things more with careful weighting.



[Medhue Simoni]

Playing with shape sliders today on the wolf. Here's some images showing the range of extremes the wolf can acheive. The small shape simply adjusts all the sliders in a way that makes those parts smaller. The large shape was done in the opposite way.



 

 

 

 

 

[DS Diavolo]

Still WIP, but I want to show some nice results with the MakeHuman Avatar 1.1 -> Blender 2.77 -> Avastar 2.0

You may notice that there are problems especially with the eyes, but a start is made :-)

 

[Medhue Simoni]

Here's a work in process. Almost done. It just needs to be cleaned up a bit. Humans might want to be weiry of requests to animate coming from large wolves.

https://i.gyazo.com/115ce7637b33096428760dcd3da8741b.gif

[Saida Hawksby]

I did not have the time or energy to read all 121 pages.  so I apologize if this has been asked/answered.  I tried looking for the answer but haven't found it.

 

Since the current facial animation system is the "morph" and limits faces to the default dozen or so animations (the ones you see activated by sex furniture sometimes).  And the hands can only be set to the few default hand positions, what does LL plan to do to open up the ability to upload animations that will affect/influence these new bones?  Because, as I understand it now, a bento head or hands could still only conform to the default morphs or you would have to script some kind of "animation" into it by having parts go systematically invisible as some things are "animated" now.

 

[Gaia Clary]

Face bones and hand bones are fully animatable with standard animation tools. You can import files in .bvh format and in Linden Lab's own internal .anim format (not to be mixed up with the Maya Animation File format that is also named .anim )

As far as i know there is (currently?) no scripting that you can use move the bones around. So you have to make your own regular animations with your favorite animation tool(s). You can use rotation and translation on all bones of your animations. However you must be aware that your animations may become less general useable because of the possible variations in the skeleton (keyword: joint offsets)

 

[Medhue Simoni]

So, uhm, I wrote a Blog about Bento. My SEO keeps telling me to write more blogs. Apparently they bring traffic. So, I did 1. Warning! Half the blog post is promoting my big wolves, but it is my site, you know. lol

http://www.medhueanimations.com/blogs/news/second-life-bento-and-large-wolves

 

@Cathy Foil - Can't you give me links to Mayastar, I want to add them to the blog?

@Polysail - Same! Can you get me links to your's for 3Ds Max?

[DS Diavolo]

A short addition with a male character. Try to watch on 4k TV! The possibilities for machinima are incredible!

 

[SeaSet]

hello all, I've been rigging a hand and I'm experiencing difficulties with joint positions. 
my hand in maya on the left, and inworld on the right.

            

 I can't figure out what causes the joints to offset like that. is there a way to fix it?  

[Polymath Snuggler]

The two images look identical?~  I'm confused.

[SeaSet]

sorry- I didn't notice the links were identical LOL!

[Polymath Snuggler]

Ty for fixing the image postings ~  As for the actual problem...  Is this what happens when you upload the file without "Use Joint Positions" checked?

It's interesting to see the bone nodes are highlighted red ~ which I've sort of assumed at this point ( with no real confirmation mind you ~ besides fiddling with it ) ~~means they're using some sort of custom orienteation/ position.

I can't speak for the accuracy of the Maya import of the rig.  People have been murmuring about "wierdness in the hands" for almost a month now and I've been unable to reproduce the problem personally. ~  That being said, I may not be doing the correct tests.

[Polymath Snuggler]

@Vir.

 

I ran into some odd slider entries in the LAD file.  I haven't quite worked out what how driven:  sliderName~ (  node#,  min1,  max1 , min2, max2 )  Entries affect their child-nodes that they refer to.

 

However.

 

One such child node has a lot of zeros in it for affected bones : 



I'm unable to tell if these zeros actually do something.  Are they redundant?  Ignorable?  Do they serve a purpose? Or did I find a rounding error of some sort?

EDIT ~ I did a little more digging and :

The following bones have slider entries that are either zero vectors for both scale and position, or just have single entries for scale or position that are zero, with no entry at all for the other field.

"SliderName: Male_Skeleton || mWingsRoot HAS ALL ZERO DATA"
"SliderName: Height || mCollarLeft HAS ALL ZERO DATA"
"SliderName: Height || mCollarRight HAS ALL ZERO DATA"
"SliderName: Height || mWing1Left HAS ALL ZERO DATA"
"SliderName: Height || mWing1Right HAS ALL ZERO DATA"
"SliderName: Frown_Mouth || mFaceLipUpperLeft HAS ALL ZERO DATA"
"SliderName: Frown_Mouth || mFaceLipUpperCenter HAS ALL ZERO DATA"
"SliderName: Frown_Mouth || mFaceLipUpperRight HAS ALL ZERO DATA"
"SliderName: Ears_Out || mFaceEar1Left HAS ALL ZERO DATA"
"SliderName: Ears_Out || mFaceEar1Right HAS ALL ZERO DATA"
"SliderName: Wide_Eyes || mFaceEyeAltLeft HAS ALL ZERO DATA"
"SliderName: Wide_Eyes || mFaceEyeAltRight HAS ALL ZERO DATA"
"SliderName: Square_Head || mFaceRoot HAS ALL ZERO DATA"
"SliderName: Egg_Head || mFaceLipLowerRight HAS ALL ZERO DATA"
"SliderName: Egg_Head || mFaceLipLowerCenter HAS ALL ZERO DATA"
"SliderName: Egg_Head || mFaceLipLowerLeft HAS ALL ZERO DATA"
"SliderName: Egg_Head || mFaceTongueBase HAS ALL ZERO DATA"
"SliderName: Arced_Eyebrows || mFaceEyebrowOuterRight HAS ALL ZERO DATA"
"SliderName: Arced_Eyebrows || mFaceEyebrowOuterLeft HAS ALL ZERO DATA"
"SliderName: Pointy_Eyebrows || mFaceEyebrowOuterRight HAS ALL ZERO DATA"
"SliderName: Pointy_Eyebrows || mFaceEyebrowOuterLeft HAS ALL ZERO DATA"

[SeaSet]

the image from SL does have 'include joint poistions' ticked on. what's bothering me is how the joints don't flow in a continous chain, for lack of a better term. 

this is what the finger joints snap back to once I take my hand off inworld: 


could it be possible that I'm going about defining custom joint positions the wrong way? I imported my hand into the bento skeleton file and used translations within maya (basically moved around the joints without rotating or scaling them) to position them where I wanted them. then I deleted history and froze transformations on all the joints. after that I skinned the hand to the finger joints only. I'm trying to create a finger joint locker mesh (probably a cube or a sphere) so I could put another hand over it, unless there's a way to choose which joints to lock on a mesh, since I only want the fingers locked.

[Polymath Snuggler]

 I'm not sure what exactly is going wrong in this case, but I do know that Maya "draws" it's bones based on their connection, rather than their rotation. ( I'm referring to the line that you see being a representation of where a node is relative to it's parent and it's child ~ rather than the direction that node itself is pointed in )  Meaning in theory ~ you can have a bone rotated in a direction, but in the Maya Viewport ~ since it's drawing "connections" but not "rotations" it looks visually like it's pointing in another~

I sadly don't know Maya skeletons that well ~ as I mostly work in 3ds max ~ but that would be my best guess here.

As for other reasons ~  well.....

Converting from SL to Maya and then back to SL again provides a bit of an odd situation.  I can't really think of a way to explain this without getting into the math of it ~ so here goes, as simple as I can manage.

All joints in SL ~ when the skeleton is in the "T-pose" rest position are rotated to euler 0 0 0 world coordinates. Which means it's Z-axis is pointed straight up to the sky.

This does not make Autodesk software happy ( both Maya and 3ds Max ) ~ as it tends to like it's bones tracked by their actual rotations~  That means bones are positioned with their Z axis pointed down the length of the bone.

Converting between the two systems gets a bit hairy and confusing ~ and a lot of things can go wrong since there's a lot of work-arounds and funkiness that we have to kind of do to compensate.

[SeaSet]

I'm afraid it doesn't only look wrong, it behaves the wrong way as well :matte-motes-stress: 
here is a test with an animation. on the left the hand is attached, and on the right it is removed. 
the broken bones seem to completely mess up animations. 


I'm assuming it has something to do with the bone orientations on the bento skeleton within maya. each individual link seems to point straight in the Y direction, instead of having its own local axis and that is kind of the same effect I'm getting inworld. 



I tried manually re-orienting the joints, but that lead to an even worse issue:



[Vir Linden]

Hi Polysail,

Well spotted! There's a couple of reasons you might see "0 0 0" entries on the sliders. One is that the "scale" field is required, so a bone that has only an offset defined will always have a "0 0 0" entry for scale as well. If the definition had offset but not scale defined, then that bone would be ignored because it was missing a required field, so it wouldn't work as intended. (We've had a few bugs in the past related to that.) The other reason would be if there's an entry that doesn't actually do anything; if both scale and offset are "0 0 0", then there's no effect on the bone. These could have gotten in there because someone was editing the sliders and was planning for the slider to have an effect on the bone, but then wound up deciding it wasn't needed. We might clean those up at some point. In any case, it should be safe to ignore those do-nothing entries when working on your 3dsmax plugin.

[Psistorm Voxel]

Hiya, once again me with a rigging issue. I've been using Polysai's excellent rig to get my female/androgynous bodies rigged, which has, after realizing I have a bone affect limit of 4, yielded some very good results and I have them ready for further processing.

However the male body is giving me some trouble. For this one, I am using the latest bento male skeleton file off the wiki page (called something akin to BentoMaleSkeletonWithPosOffsets), and initially remapped my androgynous weights to a male body on polysail's rig. I then took the male body mesh and retargeted it to the male skeleton, which had the joins appear in the right positions as far as I could see.

But upon importing into SL, the male mesh bulks up when worn on the male shape, and I'm somewhat clueless where those extra deforms come from. I've successfully done male rigs before, and iirc transfering weights from a female mesh to a male rig and retargeting was a valid process. But if I committed an obvious mistake there, I'd much appreciate being pointed toward it, since I've been at it for a few long hours now and can't find the cause.

[Polymath Snuggler]

The male skeleton is more than just joint positions ~ it's also bone-scale, which is why you're getting bunching and wierdness.  I'm getting near having a max male skeleton soon~ just been having some difficulties working through the details.

[Psistorm Voxel]

Ooh wonderful. Would retargeting from your female to your male skeleton then be more straightforward? If so, I can probably just wait and get to work on other stages, such as getting some hand poses set up in blender and making the alpha faces for the existing meshes.

If I should just follow a different workflow altogether, let me know and I'll be sure to give it a try - and once again thanks, I can't begin to say how much your work is both helping out already and going to help in the future.