After patching (both 330/patch.sh and 330/patch_anti_logincrash.sh), the game runs but models do not appear.
You'll notice the missing arch and the missing character and game object models in the screenshots attached.
Running using CrossOver Wine:
After patching (both `330/patch.sh` and `330/patch_anti_logincrash.sh`), the game runs but models do not appear.
You'll notice the missing arch and the missing character and game object models in the screenshots attached.
Running using CrossOver Wine:
```
Product Name: CrossOver
Public Version: 22.0.1
Product Version: 22.0.1.35507
Build Tag: cxoffice-22.0.1rc1
Build Timestamp: 20220922T142953Z
```
Enabled: `DXVK`, `CSMT`, `ESync`.
Running on an `Apple M1 Max`, macOS `13.1 (22C65)`.
Logs from wine: https://stuff.lhunath.com/genshin.log
A: No, the game falsely detects MacOS as a virtual machine. See Issue #12 for details.
So the fact that it even works at all, is actually news.
Edited to add: it's likely that Genshin on DXVK relies on APIs not present in MoltenVK, or otherwise not implemented yet. I would recommend not to report this to VALVe, since this project and the ability to run GI on WINE is at best tolerated, at worst something Hoy wants to quash.
Running on macOS is at best unsupported.
FAQ at https://notabug.org/Krock/dawn/src/master/FAQ.md says:
> Q: Does it work on MacOS?
>
> A: No, the game falsely detects MacOS as a virtual machine. See Issue #12 for details.
So the fact that it even works at all, is actually news.
Edited to add: it's likely that Genshin on DXVK relies on APIs not present in MoltenVK, or otherwise not implemented yet. I would recommend *not* to report this to VALVe, since this project and the ability to run GI on WINE is at best tolerated, at worst something Hoy wants to quash.
Thank you, I did spot #12 and was also happy to see the game did indeed at least run on my end. The in-game browser and most functionality seems to all be working well, models aside.
I figured the details I was able to scrape together might be beneficial to someone.
Thank you, I did spot #12 and was also happy to see the game did indeed at least run on my end. The in-game browser and most functionality seems to all be working well, models aside.
I figured the details I was able to scrape together might be beneficial to someone.
It appears that Metal 3's Mesh shaders should alleviate the issue of missing Metal APIs, but it will obviously mean we'll need to see updates in the Vulkan translation layers to adopt these.
It appears that Metal 3's Mesh shaders should alleviate the issue of missing Metal APIs, but it will obviously mean we'll need to see updates in the Vulkan translation layers to adopt these.
It appears that Metal 3's Mesh shaders should alleviate the issue of missing Metal APIs, but it will obviously mean we'll need to see updates in the Vulkan translation layers to adopt these.
For instance, see: https://github.com/KhronosGroup/MoltenVK/issues/1618#issuecomment-1234233944
Is there any change if you use wined3d instead of DXVK? You should probably just use PlayCover instead though
Edit: I went and found out, and the change is that it's worse.
Is there any change if you use wined3d instead of DXVK? ~~You should probably just use PlayCover instead though~~
Edit: I went and found out, and the change is that it's worse.
D3D using opengl does trigger the game is on LSD trip. However the models should appear for you when using mac osx with opengl. Also as of wine-8.0_rc2 the lsd trippyness is far far less then in times past, but it still happens. Crossover 22.0.1 is using wine-7.7, which is old. If you really wanted to get this issue fixed, the lsd trip thing, you could report a bug to the crossover people and then enjoy this project on mac osx. The vulkan side missing models is never going to change because of apple's policies.
D3D using opengl does trigger the game is on LSD trip. However the models should appear for you when using mac osx with opengl. Also as of wine-8.0_rc2 the lsd trippyness is far far less then in times past, but it still happens. Crossover 22.0.1 is using wine-7.7, which is old. If you really wanted to get this issue fixed, the lsd trip thing, you could report a bug to the crossover people and then enjoy this project on mac osx. The vulkan side missing models is never going to change because of apple's policies.
The vulkan side missing models is never going to change because of apple's policies.
Do you have any information that contradicts the information above regarding Metal 3, Mesh Shaders and the MoltenVK effort to adopt them?
> The vulkan side missing models is never going to change because of apple's policies.
Do you have any information that contradicts the information above regarding Metal 3, Mesh Shaders and the MoltenVK effort to adopt them?
Metal can not support VK_EXT_mesh_shader because it requires support for geometry shaders in custom formats. The reason metal can't and won't support geometry shaders for vulkan is because realitykit, the metal api for custom materials in the shader stages, supports two different types of custom metal shader functions: geometry modifiers and surface shaders. But there is no support for a geometry shader pipeline in there, and the geometry modifies vertex shaders only for realitykit's pipeline. See someone trying to implement very very slow theoretical geometry shaders on metal here https stackoverflow DOT com/questions/50557224/metal-emulate-geometry-shaders-using-compute-shaders
MoltenVK's effort to adopt apple's "mesh" shader implementation probably couldn't depend on reality kit's modifying pipeline which means they'd have to go with the hacky approach above for custom formats. If the above reference worked, it would be super super slow and prone to error. It would almost be better to do a software implementation for the custom portion or the entire portion of the geometry pipeline. As differentating formats on the fly would be a performance hit. I'm not a moltenVK developer nor did I know metal 3 was a thing until you mentioned it so I had to research how it would be possible to implement just to answer you. Looking a little further someone is trying to implement a incomplete and hacky workaround here https github DOT com/KhronosGroup/SPIRV-Cross/issues/1962 to use in moltenVK. Problem is their implementation doesn't account for being able to modify the geometry shader pipeline right now.
It's either convince apple to change their policy and release a lib to modify the geometry pipeline, a software pipeline combined into hardware for speed, or getting wine/crossover to improve their opengl implementation to implement the missing d3d parts. It would take alot less time and effort to implement the d3d parts in wine, as well as being faster overall for performance, then to convince apple or to write a custom soft and hard pipeline for various possible shader combinations.
Metal can not support VK_EXT_mesh_shader because it requires support for geometry shaders in custom formats. The reason metal can't and won't support geometry shaders for vulkan is because realitykit, the metal api for custom materials in the shader stages, supports two different types of custom metal shader functions: geometry modifiers and surface shaders. But there is no support for a geometry shader pipeline in there, and the geometry modifies vertex shaders only for realitykit's pipeline. See someone trying to implement very very slow theoretical geometry shaders on metal here https stackoverflow DOT com/questions/50557224/metal-emulate-geometry-shaders-using-compute-shaders
MoltenVK's effort to adopt apple's "mesh" shader implementation probably couldn't depend on reality kit's modifying pipeline which means they'd have to go with the hacky approach above for custom formats. If the above reference worked, it would be super super slow and prone to error. It would almost be better to do a software implementation for the custom portion or the entire portion of the geometry pipeline. As differentating formats on the fly would be a performance hit. I'm not a moltenVK developer nor did I know metal 3 was a thing until you mentioned it so I had to research how it would be possible to implement just to answer you. Looking a little further someone is trying to implement a incomplete and hacky workaround here https github DOT com/KhronosGroup/SPIRV-Cross/issues/1962 to use in moltenVK. Problem is their implementation doesn't account for being able to modify the geometry shader pipeline right now.
It's either convince apple to change their policy and release a lib to modify the geometry pipeline, a software pipeline combined into hardware for speed, or getting wine/crossover to improve their opengl implementation to implement the missing d3d parts. It would take alot less time and effort to implement the d3d parts in wine, as well as being faster overall for performance, then to convince apple or to write a custom soft and hard pipeline for various possible shader combinations.
I suppose you should take everything I say with a huge chunk of salt. Looking through https developer DOT apple DOT com/documentation/metal/shader_libraries/customizing_shaders_using_function_pointers_and_stitching I don't see anything about a geometry pipeline or specifically a way of modifying only points or triangles into eachother and adding extra variables. "Stiching" their compute pipeline would mean having to check the input against known shader formats which is confusing when you are using a custom format because then you have to do something like this https stackoverflow DOT com/questions/43701382/how-to-pass-texture-buffer-data-to-shader-with-metal . Reading through the PR mentioned for LLVM above looks like they came to a similiar conclusion without testing it. Oh i've gotten way off topic haven't I. Just ask the crossover devs to fix your issue as there is no workaround currently.
I suppose you should take everything I say with a huge chunk of salt. Looking through https developer DOT apple DOT com/documentation/metal/shader_libraries/customizing_shaders_using_function_pointers_and_stitching I don't see anything about a geometry pipeline or specifically a way of modifying only points or triangles into eachother and adding extra variables. "Stiching" their compute pipeline would mean having to check the input against known shader formats which is confusing when you are using a custom format because then you have to do something like this https stackoverflow DOT com/questions/43701382/how-to-pass-texture-buffer-data-to-shader-with-metal . Reading through the PR mentioned for LLVM above looks like they came to a similiar conclusion without testing it. Oh i've gotten way off topic haven't I. Just ask the crossover devs to fix your issue as there is no workaround currently.
Unfortunately after applying and updating, the model issue appears to persist (although somehow not as bad as before? Unsure if things changed due to your patch or due to Genshin version 350)
Note: I am running CrossOver and DXVK, and I also placed your recommended dxvk.conf in both Genshin Impact and Genshin Impact Game (I wasn't sure which one you were referring to).
Can you share what your patch does/aims to do?
Thanks 3Shain,
Unfortunately after applying and updating, the model issue appears to persist (although somehow not as bad as before? Unsure if things changed due to your patch or due to Genshin version 350)
Note: I am running CrossOver and DXVK, and I also placed your recommended dxvk.conf in both `Genshin Impact` and `Genshin Impact Game` (I wasn't sure which one you were referring to).
Can you share what your patch does/aims to do?
While the linked patch for DSP involves dll overrides and installs BepInEx. It would appear to be a bit more involved. Although I can recognize that the DSP mod itself does modify globalgamemanagers as well.
Might there be a way to apply the BepInEx solution to Genshin? Perhaps @3Shain is just missing a few steps here?
.. or maybe BepInEx is only used to load the DSP mod which is not necessary here.
Hmm, @3Shain seems to just do:
```
xxd -p -c 100000000 < "$DATADIR/globalgamemanagers.bak" | sed "s/67616d657300000001/67616d657300000000/" | xxd -r -p > "$DATADIR/globalgamemanagers"
```
While the linked patch for DSP involves dll overrides and installs BepInEx. It would appear to be a bit more involved. Although I can recognize that the DSP mod itself does modify `globalgamemanagers` as well.
Might there be a way to apply the BepInEx solution to Genshin? Perhaps @3Shain is just missing a few steps here?
.. or maybe BepInEx is only used to load the DSP mod which is not necessary here.
I'm pretty sure it does work. It just disabled `gpuSkinning` which will make **most of** models rendered properly (and `dxvk.conf` changes is an enhancement.
Could you try [this dxvk build?](https://github.com/3Shain/DXVK-macOS/releases/tag/10.3.2-4d711ac)
BepInEx is not necessary at all.
@lhunath I don't see what you're seeing. While that patcher uses BepInEx for configuration (enabling or disabling the patch), it uses AssetsTools.NET to read globalgamemanagers and modify it according to the "enabled" value in the configuation.
My assumption is that the rendering patch skips the part where it deserializes and modifies the file from the deserialized object, but ¯\_(ツ)_/¯.
Also, if it wasn't clear, don't even try to use BepInEx on the official server.
@lhunath I don't see what you're seeing. While that patcher uses BepInEx for configuration (enabling or disabling the patch), it uses AssetsTools.NET to read globalgamemanagers and modify it according to the "enabled" value in the configuation.
My assumption is that the rendering patch skips the part where it deserializes and modifies the file from the deserialized object, but ¯\\\_(ツ)\_/¯.
Also, if it wasn't clear, **don't** even try to use BepInEx on the official server.
Ahh that doesn't make sense to me...I thought crossover should have a not-too-old dxvk which support such configuration. But at least using crossover with recent dxvk-macos manually installed should work (while I can't confirm it yet).
Ahh that doesn't make sense to me...I thought crossover should have a not-too-old dxvk which support such configuration. But at least using crossover with recent dxvk-macos manually installed should work (while I can't confirm it yet).
@3Shain The problem is that the dxvk CrossOver uses dosen't support the feild dxgi.customDeviceDesc. So, I tried to set both device ID and vendor ID to match AMD Radeon Pro 5300M (7340 and 1002), but it did not work. I don't know if there is an alternative solution.
Devs at CodeWeavers are still using an incredibly old dxvk version from April 8th, 2021.
@3Shain The problem is that the dxvk CrossOver uses dosen't support the feild `dxgi.customDeviceDesc`. So, I tried to set both device ID and vendor ID to match AMD Radeon Pro 5300M (7340 and 1002), but it did not work. I don't know if there is an alternative solution.
You can find the example `dxvk.conf` file of CrossOver here in their latest source code release: https://www.codeweavers.com/
https://media.codeweavers.com/pub/crossover/source/crossover-sources-22.1.0.tar.gz
Devs at CodeWeavers are still using an incredibly old dxvk version from April 8th, 2021.
After patching (both
330/patch.shand330/patch_anti_logincrash.sh), the game runs but models do not appear. You'll notice the missing arch and the missing character and game object models in the screenshots attached. Running using CrossOver Wine:Enabled:
DXVK,CSMT,ESync. Running on anApple M1 Max, macOS13.1 (22C65). Logs from wine: https://stuff.lhunath.com/genshin.logRunning on macOS is at best unsupported.
FAQ at https://notabug.org/Krock/dawn/src/master/FAQ.md says:
So the fact that it even works at all, is actually news.
Edited to add: it's likely that Genshin on DXVK relies on APIs not present in MoltenVK, or otherwise not implemented yet. I would recommend not to report this to VALVe, since this project and the ability to run GI on WINE is at best tolerated, at worst something Hoy wants to quash.
Thank you, I did spot #12 and was also happy to see the game did indeed at least run on my end. The in-game browser and most functionality seems to all be working well, models aside. I figured the details I was able to scrape together might be beneficial to someone.
It appears that Metal 3's Mesh shaders should alleviate the issue of missing Metal APIs, but it will obviously mean we'll need to see updates in the Vulkan translation layers to adopt these.
It appears that Metal 3's Mesh shaders should alleviate the issue of missing Metal APIs, but it will obviously mean we'll need to see updates in the Vulkan translation layers to adopt these. For instance, see: https://github.com/KhronosGroup/MoltenVK/issues/1618#issuecomment-1234233944
Is there any change if you use wined3d instead of DXVK?
You should probably just use PlayCover instead thoughEdit: I went and found out, and the change is that it's worse.
D3D triggers the "Game is on an LSD trip" section in
TROUBLESHOOTING.md.D3D using opengl does trigger the game is on LSD trip. However the models should appear for you when using mac osx with opengl. Also as of wine-8.0_rc2 the lsd trippyness is far far less then in times past, but it still happens. Crossover 22.0.1 is using wine-7.7, which is old. If you really wanted to get this issue fixed, the lsd trip thing, you could report a bug to the crossover people and then enjoy this project on mac osx. The vulkan side missing models is never going to change because of apple's policies.
Do you have any information that contradicts the information above regarding Metal 3, Mesh Shaders and the MoltenVK effort to adopt them?
Metal can not support VK_EXT_mesh_shader because it requires support for geometry shaders in custom formats. The reason metal can't and won't support geometry shaders for vulkan is because realitykit, the metal api for custom materials in the shader stages, supports two different types of custom metal shader functions: geometry modifiers and surface shaders. But there is no support for a geometry shader pipeline in there, and the geometry modifies vertex shaders only for realitykit's pipeline. See someone trying to implement very very slow theoretical geometry shaders on metal here https stackoverflow DOT com/questions/50557224/metal-emulate-geometry-shaders-using-compute-shaders
MoltenVK's effort to adopt apple's "mesh" shader implementation probably couldn't depend on reality kit's modifying pipeline which means they'd have to go with the hacky approach above for custom formats. If the above reference worked, it would be super super slow and prone to error. It would almost be better to do a software implementation for the custom portion or the entire portion of the geometry pipeline. As differentating formats on the fly would be a performance hit. I'm not a moltenVK developer nor did I know metal 3 was a thing until you mentioned it so I had to research how it would be possible to implement just to answer you. Looking a little further someone is trying to implement a incomplete and hacky workaround here https github DOT com/KhronosGroup/SPIRV-Cross/issues/1962 to use in moltenVK. Problem is their implementation doesn't account for being able to modify the geometry shader pipeline right now.
It's either convince apple to change their policy and release a lib to modify the geometry pipeline, a software pipeline combined into hardware for speed, or getting wine/crossover to improve their opengl implementation to implement the missing d3d parts. It would take alot less time and effort to implement the d3d parts in wine, as well as being faster overall for performance, then to convince apple or to write a custom soft and hard pipeline for various possible shader combinations.
I suppose you should take everything I say with a huge chunk of salt. Looking through https developer DOT apple DOT com/documentation/metal/shader_libraries/customizing_shaders_using_function_pointers_and_stitching I don't see anything about a geometry pipeline or specifically a way of modifying only points or triangles into eachother and adding extra variables. "Stiching" their compute pipeline would mean having to check the input against known shader formats which is confusing when you are using a custom format because then you have to do something like this https stackoverflow DOT com/questions/43701382/how-to-pass-texture-buffer-data-to-shader-with-metal . Reading through the PR mentioned for LLVM above looks like they came to a similiar conclusion without testing it. Oh i've gotten way off topic haven't I. Just ask the crossover devs to fix your issue as there is no workaround currently.
Check this https://notabug.org/Krock/dawn/pulls/394
Thanks 3Shain,
Unfortunately after applying and updating, the model issue appears to persist (although somehow not as bad as before? Unsure if things changed due to your patch or due to Genshin version 350)
Note: I am running CrossOver and DXVK, and I also placed your recommended dxvk.conf in both
Genshin ImpactandGenshin Impact Game(I wasn't sure which one you were referring to).Can you share what your patch does/aims to do?
@lhunath I believe it does what this does: https://github.com/andyoneal/DSPMac
Hmm, @3Shain seems to just do:
While the linked patch for DSP involves dll overrides and installs BepInEx. It would appear to be a bit more involved. Although I can recognize that the DSP mod itself does modify
globalgamemanagersas well. Might there be a way to apply the BepInEx solution to Genshin? Perhaps @3Shain is just missing a few steps here?.. or maybe BepInEx is only used to load the DSP mod which is not necessary here.
I'm pretty sure it does work. It just disabled
gpuSkinningwhich will make most of models rendered properly (anddxvk.confchanges is an enhancement.Could you try this dxvk build?
BepInEx is not necessary at all.
@lhunath I don't see what you're seeing. While that patcher uses BepInEx for configuration (enabling or disabling the patch), it uses AssetsTools.NET to read globalgamemanagers and modify it according to the "enabled" value in the configuation.
My assumption is that the rendering patch skips the part where it deserializes and modifies the file from the deserialized object, but ¯\_(ツ)_/¯.
Also, if it wasn't clear, don't even try to use BepInEx on the official server.
@3Shain The
dxvk.confpatch works on your custom wine 7.7 with (unpatched) dxvk-macos 1.10.3-47, but not crossover 22.1.Ahh that doesn't make sense to me...I thought crossover should have a not-too-old dxvk which support such configuration. But at least using crossover with recent dxvk-macos manually installed should work (while I can't confirm it yet).
@3Shain The problem is that the dxvk CrossOver uses dosen't support the feild
dxgi.customDeviceDesc. So, I tried to set both device ID and vendor ID to match AMD Radeon Pro 5300M (7340 and 1002), but it did not work. I don't know if there is an alternative solution.You can find the example
dxvk.conffile of CrossOver here in their latest source code release: https://www.codeweavers.com/ https://media.codeweavers.com/pub/crossover/source/crossover-sources-22.1.0.tar.gzDevs at CodeWeavers are still using an incredibly old dxvk version from April 8th, 2021.
Documented as of 728358d.