R2 DAE Upload issues with Firestorm 6.0.1.56538 Beta

[aiaustin]

Firestorm 5.1.7 appears to upload the exported DAE we have been using... but the latest 6.0.1 Beta gives some issues...

I am uploading DAE with the normal recommended settings (from the Ruth Wiki page)... selecting "Avatar Shape" as the type of upload, making physics "Low" and ticking the box for "Include skin weight".. but when I then do the "calculate weights and fee" it reports a problem...

"Warning: a bind shape matrix is not in standard X-forward orientation"

It did though in some cases still offer me the Upload button and when uploaded the mesh does appear to be okay in world. Should we ignore that warning?

I checked some other parts though (such as some feet and hand options) and as well as the bind shape matrix warning shows I get an error in the uploader that will not allow me upload those parts at all.

"Physics mesh too dense; remove the small, thin triangles (see preview)"

This may be a general issue on all Ruth and Roth meshes... I just checked on Ruth Too (Sean Heavy) body mesh DAE parts and those give the same error. Could be we have a problem with Firestorm 6.0.1?

[aiaustin]

Looks like Firestorm 6.0.1 and in preparation for Animesh the Mesh uploader is now much stricter in looking for Mesh Asset Validation (MAV) "errors" and Ruth/Roth mesh DAE exports appear to trigger these. See this blog post for some background... http://beqsother.blogspot.com/2018/12/easing-pain-of-importing-mesh.html

A work around for the moment is to upload with Firestorm 5.1.7.

[aiaustin]

I wonder if the warning on all the Ruth and Roth mesh uploads for "Warning: a bind shape matrix is not in standard X-forward orientation" might explain why the body parts load at an angle to the avatar prior to snapping into position after they are fully loaded? Maybe that issue can be fixed by rotating the meshes in Blender but leaving the rigging intact? Just a guess.. I am not an experienced Blender user or Collada exporter.

[TaarnaWelles]

Original, a long time ago, before Avastar, the armature rotation was on the X-forward. I have no information on why it was changed to Y-forward but since then we build in the Y-forward. The Y-forward is in almost every 3D program a default setting when you start modeling. Even then, we have to deal with the too dense part. For example, the feet or hands are separate and have their own topology and to match with the body you have to make changes, such as more tris or less tris (triangles instead of quads). You can change them, but then we get another issue. That's the UV map. The UV map is the same as the original system UV map and supposes you change the UV map, no custom or system skin will match.

I'm not a pro, so my explanation could be not precise enough, but it gives you an idea why or maybe why we get a warning now. There's always a difference between SL or Opensim. In SL your mesh has to be much more precise than in Opensim.

Does this make sense?

On Mon, Jan 7, 2019 at 11:41 AM Ai Austin notifications@github.com wrote:

I wonder if the warning on all the Ruth and Roth mesh uploads for "Warning: a bind shape matrix is not in standard X-forward orientation" might explain why the body parts load at an angle to the avatar prior to snapping into position after they are fully loaded? Maybe that issue can be fixed by rotating the meshes in Blender but leaving the rigging intact? Just a guess.. I am not an experienced Blender user or Collada exporter.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ingen-lab/Ruth/issues/42#issuecomment-451894054, or mute the thread https://github.com/notifications/unsubscribe-auth/AJJsvUjbYSE_EUO8hVAsqwO-ihgXp6B2ks5vAyRngaJpZM4Zygn8 .

[aiaustin]

Many thanks for the explanation Taarna... it may also explain why some avatars I have taken in from FBX converted to DAE also appear side ways on the avatar while the mesh loads... it is pretty ugly and kills immersion. But that warning does not prevent an upload in Firestorm 6.0.1.

The thin triangles problem is different and stops upload in 6.0.1.

Maybe we have to start a conversation with viewer developers to have weaker error checking and upload prevention for OpenSim?

[uriesk]

That was an issue with firestorm itself, when creating LoD levels, the viewer sometimes creates some degenerate triangles (triangles with 0 area). With the new check (in fact, that check was always there in the code, but it was buggy and deactivated and it got fixed with Firestorm 6 Beta), the Physics Shape gets rejected if it has degenerates or too dense triangles. In SL, the Analyze button can fix that, but in OpenSim, this button isn't available, because its creating a physics shape that's for LL Havok (that we don't have in OpenSim)

But the Bug apparently got fixed now and the LoD levels shouldn't contain degenerates anymore (i didn't test it yet). https://jira.phoenixviewer.com/browse/FIRE-23387

[aiaustin]

uriesk... great you are covering this with the Firestorm JIRA and team. The fix seems to be a new Viewer debug setting to treat the “error” as a warning only. We maybe should ask that this is enabled by default on OpenSim?

The current Ruth mesh DAE uploads for hands and flat feet are not uploadable in 6.0.1 Beta.

[uriesk]

Tested uploading Ruth with a freshly compiled firestorm and it did work. It is fixed already, no need for setting an Debug option, next Firestorm update will be ok again.

[aiaustin]

Many thanks for confirming that uriesk.

[uriesk]

Issue is fixed in Firestorm 6.0.2 that is released now. If you still can't upload, you can set the debug setting FSIgnoreClientsideMeshValidation to true and try again.

[aiaustin]

This does not seem to work with Firestorm 6.0.2.56680 (SL+OS 64 bit) on some of the recent RC#3 DAE uploads. For example this mesh (when selecting any level of physics) still reports "physics mesh is too dense; remove the small, thin triangles" even with FSIgnoreClientsideMeshValidation = true.

From Sean Haevy's RuthToo RC3 DAE uploads... https://github.com/ocsean/RuthToo/tree/master/DAEs RuthToo_RC3_FingernailsMedium1.dae

Can you try that uriesk? Maybe its meant to report the issue and just allow upload anyway? I am checking also at https://jira.phoenixviewer.com/browse/FIRE-23387

[uriesk]

Sorry for the late answer, when i upload rigged mesh, i do it like that:

1. Upload it without choosing anything in the physics tab. Because its supposed to be always worn, it will never be part of any physics calculation, so why bother with it? I did this just right now with the fingernails, it worked perfectly fine and fast. I uploaded it with Firestorm 6.0.2 on a OpenSim 0.9.1 region.
2. If that doesn't work, because the viewer couldn't calculate a good convex hull and the sim complains about "missing physics convex block", i just choose the Lowest LOD model as physics model. I tried this with your fingernails, i did set LOD Lowest to 0 and used Lowest as physics shape, it also works with no error.
3. If that doesn't work, because the Lowest LOD model is useless as physics model (cause it has long triangles or whatever caused the degenerate check to fail), i just create a .dae with simple boxes (or triangular pyramids, the smallest manifold object) and use that file as physics shape. This always works. If you can't upload a mesh even though that your physics models are just pyramids, it's time to fill a Bug report. That of course also works with your fingernails.

If you want to provide the best product possible, you will always do 3, it has the least impact, even less than 1, because the viewer will always create a convex hull, if you do not select any physics, it will do it based on the highest LOD model. In the example of the fingernails, 1. would create a convex hull of ~350 triangles + empty physics shape of 0 triangles, 3. would create a physics shape of 4 triangles (pyramid) and a convex hull based on that physics shape that also has 4 triangles (cause the pyramid is already convex).

But you also have additional options if you are lazy: If 1. doesn't work because of "missing physics convex block", you can go to an old 0.8 sim (metropolis sandboxes) and upload there. It will upload fine, but that mesh will then be trashy and weird things can happen on sims that are not running BulletSim. If 2. doesn't work because of the degenerate check, you can set FSIgnoreClientsideMeshValidation to true, it will then still display the red warning, but you will still be able to upload it. It's totally ok to do that when uploading attachments.

btw. never use LoD High or Highest as Physics Model, this is never a smart idea, under no circumstances.

[aiaustin]

An excellent summary. Thanks uriesk.