Soft Attachments Cross Compatability issues causing All attachments to stop working


#1

Now that we have gotten the Pre/Post rotation solved, there is a new one in the horizon.
Specifically Attachments, and Soft attachments.

I noticed that If I try attach a clothing that works with the Avatar Standard, it works nearly as is. Feel free to test it as well (only the upper body of the earlier avatar test) More we get this tested, the better.

Aside from the issues regarding not being able to hide / set material properties of anything yet. As soon as that is an ability, we can standardized so that we can define different transparencies settings for the created avatars for various clothing patterns (long, short shirts, shorts, long pants, skirts, etc) for easier hiding via script.

Here, you guys can just note that right now it only seems to work with Blender exporter avatars, simply attach it to your avatar, set it to your hips, and enable soft avatars: Creating these is now as simple as creating an avatar with the Standard.

If testing this on other avatars on the market, mainly the Maya ones, the attachment system begins to bug up:

First the Avatars on the market cause the soft attachment to scale oddly: Lengthwise they are correct, but they remain scaled as if the avatar it self are 100x larger so they are extremely thin. Same occurs when trying to attach the example soft attachment onto the blender avatar, but in reverse. This just might be something to do with getting the scaling correct for the avatar standard and shouldnt be an issue, until we figure out the actual scale required but regardless this causes the following bug:

After a few minutes of changing avatars from different suites, and fiddling around, all attachments will dissapear and the following error is thrown:

[WARNING] QQmlExpression: Expression file:///C:/Program Files/High Fidelity/resources/qml/hifi/dialogs/attachments/Attachment.qml:77:24 depends on non-NOTIFYable properties:

And this sticks with all avatars and breaks the entire attachment system, regardless of what you do until you clear all hifi appdata files.

CC: @Ozan, @Chris, @hyperlogic


#2

Re hiding parts of the avatar what are you thinking? When I did this I tend to just make parts of the mesh transparent are you suggesting a different method?


#3

Basically this but being able to set it in world without jumping out to hide out parts/re-export., for example the transparency mask or value of an avatar material to something else.


#4

Thinks that would be unlikely as we seem to be going the “lets make everything as difficult to do as possible” route
imagines it requiring a script to load and change out the textures listed in the original texture window in the entity properties section.
as the minimum spec user seems to be thoys then the job is laughably simple for the demographic


#5

As soon as we can change the material parameters of any entities via script,
I will refocus my efforts to make an edit.js like UI to adjust current avatars on the go and try to get it bundled default.

Maybe even improve it with sliders for stuff such as Blendshape adjustment for body sizes if such support will ever come.

Because of this moment I consider everything having to be done as Hifi clearly has stated on focusing on the Oculargasm

I already tested Texture swapping, which seems to work fine, it is just that

texture-name: "http://url" 

Format just doesnt make as much sense as much as good old JSONObject.

Forexample,

String EntityObject.originalTextures lists all the entity’s textures and points with the above format per each defined texture name (from blender) and the url currently used for the texture. You can change it, and then set

EntityObject.textures = "texture-name: 'newUrl'\n texture-name-2: 'anotherUrl'"

I only discovered the above yesterday while looking at @sam s changes to allow Stingray materials: You can even do these modifications onto entities already with the current edit.js. It is just not very nice looking interface, and would make sense to be a json object for proper material modifications.

Currently though, it allows one to swap named textures and not do anything with the materials.


#6

Cloth physics - that is the proper way, at least for soft attached parts.


#7

I’m pretty sure this first issue is due to differences in scale between the clothing and the avatar wearing the clothing. We would like to support avatars authored at any unit scale, but for the moment you’ll have the best results using centimeters.

Not sure about this one, our dialogs are undergoing an overhaul, so that they can be used while wearing an HMD. Perhaps there is a bug where the attachment dialog breaks/crashes after heavy use.

This is bad, I’ve never seen this. The attachment data gets stored in the Interface.ini file. Could you attach a version of this file after it’s been corrupted? That would help us track down the issue.

Thanks


#8

Sure,

This was in Build 4295 and a tad bit earlier. I think the Error message might actually occur on -all- attachments, causing them not rez at all. The AV is just a testing thing I made,

http://www.norteclabs.com/HF/debug/Interface.ini

I removed the account information from it, but if that ini file is used.
Even after clearing cache and app data, I think I cant even rez regular attachments, the error seems to be persistant. Going to try reinstalling

http://www.norteclabs.com/HF/objects/Torch.fst


#9

As Confirmation, Yes, this seems to be occuring with all attachments, not just the soft attachments and with any avatars (thus simply attachments are broken).

[02/26 21:49:35] [WARNING] QQmlExpression: Expression file:///C:/Program Files/High Fidelity/resources/qml/hifi/dialogs/attachments/Attachment.qml:77:24 depends on non-NOTIFYable properties:
[02/26 21:49:35] [WARNING]     MyAvatar::jointNames

Seems to be quite repeatable.


#10

It could be a problem if one of the things being attached is not a valid fbx file, in this case we don’t support avatar fst files being attached to an avatar.


#11

This also occurs with a direct link the the fbx
http://www.norteclabs.com/HF/objects/Torch/Torch_High.fbx which is a static object.

The Fst files also used to work, and it is something which the packager makes when you define Avatar attachments.

Edit: Confirming this still working in Build 4239, 4265, 4284,4292 Works. (fst version as well, which I use to point towards the texture folders.)


#12

I located that somewhere between 4293-4294 the Attachment system went broken. CC: @hyperlogic


#13

Good catch, yeah it looks like a recent change broke attachment rendering.

Please try this PR build to see if it fixes the issue for you.


#14

There seems to be odd attachment bugs still going on. Now locally the attachments are not loading anylonger, unless the lod is throttled.


#15

Bumping this because the above is still a bug on the local client (everyone else sees everyone elses attachments, but their self, even if camera is moved around and LOD is messed around with, regardless if Rigged or Normal attachments and regardless of avatar…

CC: @chris