MAV_PASSING_ERROR

[VirtualKitten]

 MAV PARSING ERROR and 

LOD3 Model Circle.001 loaded
non-identity bind shape rot. mat is { 0, -0.548086, 0, 0; 0.590287, 0, 0, 0; 0, 0, 0.58955, 0; 0.596632, -8.15473, 15.426, 1 } bind_rot { 0, 0, 0.707107, 0.707107 }
non-identity bind shape rot. mat is { 0, -0.590931, 0, 0; 0.576035, 0, 0, 0; 0, 0, 0.555029, 0; 0.548386, -19.9081, 18.143, 1 } bind_rot { 0, 0, 0.707107, 0.707107 }
non-identity bind shape rot. mat is { 0, -26.4651, 0, 0; 24.9592, 0, 0, 0; 0, 0, 22.8649, 0; -13.3885, 9.66861, 13.3398, 1 } bind_rot { 0, 0, 0.707107, 0.707107 }
non-identity bind shape rot. mat is { 0, -26.908, 0, 0; 24.6479, 0, 0, 0; 0, 0, 22.8649, 0; 13.9829, 9.94171, 13.3396, 1 } bind_rot { 0, 0, 0.707107, 0.707107 }
non-identity bind shape rot. mat is { 0, -112.54, 0, 0; 52.627, 0, 0, 0; 0, 0, 29.5265, 0; 0.253345, 32.9732, 14.4152, 1 } bind_rot { 0, 0, 0.707107, 0.707107 }
non-identity bind shape rot. mat is { 0, -112.54, 0, 0; 52.627, 0, 0, 0; 0, 0, 29.5265, 0; 0.253345, 32.9732, 14.4152, 1 } bind_rot { 0, 0, 0.707107, 0.707107 }

with binding shape matrix is not in standard X-orientation my red axis is correct ?What is a bind shape rot. mat?

 

[VirtualKitten]

I think I remember having to Reset rotations and everything but did that i did tis in object mode clear rotation scale an location  but had no affect

Edited May 21, 2021 by VirtualKitten

[VirtualKitten]

Very strange orientation how do i resolve this please ?

Edited May 21, 2021 by VirtualKitten

[VirtualKitten]

I got around binding set origin of model to world but have error here Calculating model data.
LLFloaterModelPreview::setModelPhysicsFeeErrorStatus(13107200 : )

Edited May 21, 2021 by VirtualKitten

[VirtualKitten]

LOD4: List of models does not include mGroinb
Assigning LOD3 for mGroinb to found match mGroinb
Assigning LOD2 for mGroinb to found match mGroinb_LOD2
Assigning LOD1 for mGroinb to found match mGroinb_LOD1
Assigning LOD0 for mGroinb to found match mGroinb_LOD0
LLFloaterModelPreview::setModelPhysicsFeeErrorStatus(13107200 : )

[VirtualKitten]

These error messages get worse who come up with this stuff cant we have English  Why does it have to be the groin ROLF

Were is Groinb coming from  i don't think i have a vertex group called this

Edited May 21, 2021 by VirtualKitten

[VirtualKitten]

Further more it shows this is supposed to be associated with mAnkleLeft in fact pretty much everything in left list  which its not idk sighs 

 

Yet I cannot find not nodes with this on 

 

Further more if i going to edit and select everything in Groin group would you not expect whole  everything in left to be selected ?

See for yourself can you find it selected anywhere else ?

Can you help @Quarrel Kukulcan

Hugs Dx

Edited May 21, 2021 by VirtualKitten

[VirtualKitten]

Surely then this error message is a nonsense caused by Second life  for another purpose? Could you explain please as it seems very strange ?

[VirtualKitten]

I now get a different one  about grin what do these messages mean please as they done seem to associate with anything

https://i.gyazo.com/f6eb98a7102a93569dcff4ee0b9c106e.png

 

Kind Regards

Dx

Edited May 21, 2021 by VirtualKitten

[VirtualKitten]

i really don't know what these messages mean does anyone ?

This is what it does importing into second life please see link video https://i.gyazo.com/4b7d5024d1b4d61a70bc9cdd344d0f19.mp4

Edited May 21, 2021 by VirtualKitten

[VirtualKitten]

Aquila told me he could upload the mesh and it was 600L  and was very large i wonder if this error is associated with the Second life scale importer ass i have this set at 0.25  in Firestorm x64 Upload?

[Aquila Kytori]

When uploading the dragon armature as an Animation the SL animation importer throws up the error "Unable to read animation file, Incorrect root joint name, use "hip".

 

A very simple Stick_man model rigged using the same (I hope it is the same) "bento" rig and animated to move the left leg forwards and the right arm back, imports without an error. Note that the armature/model had to be rotated so that  Y axis is Forwards   and   Z axis is Up  otherwise the  limbs were rotated incorrectly ( and Scale set to 39.3701 meters to inches. I am not sure yet how important this scale setting is. its just something I read in an earlier thread).

 

If I understand correctly something Optimo mentioned in an earlier thread; the .bvh (or was it the SL importer ?) looks for a bone named hip to use as root  but if it doesn't find that it will accept mpelvis instead. I checked and the dragon does have the mpelvis bone. (I also tried renaming the mPelvis to hip but same error).

Does anyone have any ideas what what could be causing this error ?

Edited May 28, 2021 by Aquila Kytori

[Aquila Kytori]

The reason the animation importer was throwing up that error was because the dragon skeleton had two bones that should not have been there. Bone and Bone.001.

Deleting those two bones will enable you to import an animation without an error.

 

Uploading an animation which rotates the mShoulderLeft bone   of the dragon :

 

Here is a video that explains how to animate the model in the standing up position while still having the base model/armature using  Y up    and     Z forwards.

 

Enable the subtitles/captions for an explanation for how this works.

 

[Aquila Kytori]

Correction to my earlier post :

On 5/28/2021 at 9:12 PM, Aquila Kytori said:

A very simple Stick_man model rigged using the same (I hope it is the same) "bento" rig and animated to move the left leg forwards and the right arm back, imports without an error. Note that the armature/model had to be rotated so that  Y axis is Forwards   and   Z axis is Up  otherwise the  limbs were rotated incorrectly

It should have been    Z axis is Forwards    and      Y axis is Up .

 

[OptimoMaximo]

On 5/28/2021 at 9:12 PM, Aquila Kytori said:

If I understand correctly something Optimo mentioned in an earlier thread; the .bvh (or was it the SL importer ?) looks for a bone named hip to use as root  but if it doesn't find that it will accept mpelvis instead.

The bvh importer should accept a few aliases for each single bone, I guess to allow scenes with multiple rigs in 3d applications without name clashing, of which the root can be mPelvis, hip, avatar_hip... But! To my knowledge only hip works and that's how Cathy Foil and I have set up the animation export with that naming convention in our exporters. The anim format, instead, doesn't allow aliases, so for the anim exporter I resorted to some name strings manipulation to get the desired output.

The scale set at 39.37 refers to the centimeters to inch conversion rate when the avatar is based on a centimeters scale where the linear units are centimeters and the unit itself has to be interpreted as inches, so I don't know if that still applies in Blender, which is based on meters as linear unit. I guess it would need to be converted to inches, requiring the inverse ratio to be applied. Anyway, importing a bvh animation without scale compensation results in a skeleton that is smaller than its counterpart in meters scale. Quite a fuss and pretty dumb design.

Edited May 30, 2021 by OptimoMaximo
Edited scale factor. Well spotted Quarrel 😁

[Quarrel Kukulcan]

4 hours ago, OptimoMaximo said:

The scale set at 39.7 refers to the centimeters to inch conversion rate when the avatar is based on a centimeters scale where the linear units are centimeters and the unit itself has to be interpreted as inches

Are you sure? 39.37 (not 39.7, which looks like a typo) is the meters-to-inches conversion factor. That's what I'd expect to need if the skeleton in Blender is about 2 units tall.

[OptimoMaximo]

3 minutes ago, Quarrel Kukulcan said:

Are you sure? 39.37 (not 39.7, which looks like a typo) is the meters-to-inches conversion factor. That's what I'd expect to need if the skeleton in Blender is about 2 units tall.

That's what the Maya base scale avatar has to be scaled up to in order to comply to the inches scale that bvh for SL expects. In Maya the avatar is almost 2 units tall, meaning almost 2 centimeters, and to get it to animation standards for bvh export it must be scaled up by 39.37, because that is the inches to meters scale factor. In Blender, based on meters, you should scale things down to get the actual size in inches to comply to the SL Bvh standards.