search

d4rkc0d3r / d4rkAvatarOptimizer

d4rkpl4y3r's VRChat Avatar 3.0 optimizer
MIT License
368 stars 16 forks source link

VRCFury 1.896 compability issues #103

Closed jerryzmtz closed 3 months ago

jerryzmtz commented 3 months ago

I have met an issue that d4rk optimizer is not optimizing materials after VRCFury executions only during uploads.

Here is the base environment:

Unity 2022.3.22f1 SDK 3.5.2 NDMF 1.4.0 Modular Avatar 1.9.12 d4rk 3.6.3

d4rk optimizer settings image

Here is what I have tested:

  1. Basic Environment + VRCFury 1.861.0: Everything is OK in upload, play mode and test copies (Order: NDMF build test copies, VRCFury build test copies, d4rk optimizer optimize) . Materials look like this image

  2. Basic Environment + VRCFury 1.898.0: Everything is OK in play mode and test copies(Order: NDMF build test copies, VRCFury build test copies, d4rk optimizer optimize) . But during upload, it seems that d4rk is not optimizing materials so that poiyomi is locking every materials. Materials look like this: image

Besides, some original materials turn pink after upload. And I cannot find a rule about which one to turn and which one does not. image

The pwd is debug. debug.zip

SenkyDragon commented 3 months ago

We did some brief debugging over discord, and it seems that for some reason d4rk is not optimizing the materials during this build at all. VRCF is properly detecting that d4rk is present (and thus does not trigger poi to lockdown), but then d4rk doesn't do anything, so poi's build hook sees vrcf's unlocked mats and then locks them down itself.

Not sure why d4rk isn't optimizing the materials here, or why it would have worked on a previous version of vrcf. Afaik, we're not doing anything that would inhibit d4rk from seeing or optimizing the mats.

d4rkc0d3r commented 3 months ago

Does the optimizer run at all during upload or is it just the material locking that doesn't? You can check that either by looking if the optimizer progress bar pops up or by deleting the trash bin folder and checking if it generated anything after upload.

jerryzmtz commented 3 months ago

Does the optimizer run at all during upload or is it just the material locking that doesn't? You can check that either by looking if the optimizer progress bar pops up or by deleting the trash bin folder and checking if it generated anything after upload.

It seems that d4rk dose not run at all. In the debug file I have provided, there are two files: Trashbin after VRCFury 1.861.0 build and Trashbin after VRCFury 1.896 build. They are exactly the same

d4rkc0d3r commented 3 months ago

That probably means that IEditorOnly components get yeeted before my optimizer callback gets activated. I do have a special hack that makes my callback order -15 if MA exists and its -1025 otherwise. If you don't mind touching the code you could try to remove that check in AvatarBluidHook.cs and only keep the line with callback order -1025 to see if it runs then.

https://github.com/d4rkc0d3r/d4rkAvatarOptimizer/blob/v3.6.3/Editor/AvatarBuildHook.cs#L13-L19

SenkyDragon commented 3 months ago

The vrcsdk always removes all IEditorOnly components at -1024. VRCFury inhibits this removal if it's an editor test build or while in play mode, which would explain why the issue would only happen during a real upload. I'm not sure how MA + d4rk without VRCF would ever work though.

d4rkc0d3r commented 3 months ago

// Modular Avatar is at -25, we want to be after that. However usually vrcsdk removes IEditorOnly at -1024. // MA patches that to happen last so we can only be at -15 if MA is installed otherwise our component will be removed before getting run.

I wrote this back before NDMF was a thing but it just kept working. The reason I didn't just go to -1025 is because then its on the same order as NDMF optimization pass which I want to happen before my optimizer...

SenkyDragon commented 3 months ago

Ah, that explains why I couldn't find the priority hack. Seems strange that it's still in MA and not in NDMF.

In that case, I think this may be a hack conflict between VRCF and MA. VRCF also wraps the VRCSDK's editor-only removal, and that wrapper probably prevents MA from finding it and moving it to the end. That's something I can fix. I can't see any good reason that the removal would be anything aside from MaxInteger, so I'll probably just do the same thing that MA does so it doesn't matter who "wins."

SenkyDragon commented 3 months ago

This should be fixed with vrcfury 1.904