looks like lib astc is missing from the build or the command line.
I got astc-encoder.lib from building BabylonNative - is it equivalents with libastc.a?
And I found this from Github; Does playground app affects built libraries?
I guess it may, since BabylonNative.sln doesn’t have specified any version of WinRT nuget pkg and files related to WinRT are already supporting Microsoft::UI::Xaml.
(old UWP apps uses Windows::UI::Xaml)
yes, IIRC it’s astc-encoder.lib
Does playground app affects built libraries?
I’m not sure to understand your question.
You’re right! I found that I accidently omitted astc-encoder.lib in my pch.h.
Just included it, now bimg.lib error has gone, but MachineIndependentd.lib(ShaderLang.obj) error still occurs.
And, with apologize for my bad english;
Does playground app affects built libraries?
This means if I change the Playground app of BabylonNative git repo (e. g. replace the UWP app to WinUI 3 app), will it also change *.lib files generated by running ALL_BUILD on BabylonNative.sln?
Playground app is the final build. So, modification of the app source will have no impact in babylonnative libraries.
Okay, then it won’t affect library files.
MachineIndependentd.lib(ShaderLang.obj) error is now gone - I finally found the last library I omitted.
The only error left is LNK2038, but it seems to be I cannot modify C++/WinRT versions of RN new arch app - so I have to recompile BN tomorrow (in here South Korea, it’s almost midnight now)
I remember somewhere C++/WinRT ver. 2.0.220110.5 was hardcoded, but I’m not sure it existed.
I now found that RN new arch app requires Win32 libraries, not UWP libraries. so I rebuilt for Win32(x64).
But now I’m suffering from g_graphicsDevice->UpdateWindow(m_graphicsConfig.Window); - it crashes with
LNK2019: "public: void __cdecl Babylon::Graphics::Device::UpdateWindow(struct winrt::Windows::Foundation::IInspectable)" (?UpdateWindow@Device@Graphics@Babylon@@QEAAXUIInspectable@Foundation@Windows@winrt@@@Z)"public: void __cdecl BabylonNative::ReactNativeModule::UpdateGraphicsConfiguration(void)" (?UpdateGraphicsConfiguration@ReactNativeModule@BabylonNative@@QEAAXXZ)
If commentate that line, I can launch RN app, but stuck in “Could not initialize Babylon Native” Screen. even these not work in new arch:
host.InstanceSettings().UseDirectDebugger(false);
host.InstanceSettings().UseDeveloperSupport(false);
host.InstanceSettings().UseWebDebugger(false);
So I set to ignore isRemoteDebuggingEnabled by force, then the app bangs on Napi::Attach
You can try my npm package via Github with modified @babylonjs/react-native/BabylonModule.js:
import { TurboModuleRegistry } from 'react-native';
const BabylonModule = require('../react-native-windows/NativeBabylon').default;
export async function ensureInitialized() {
await BabylonModule.initialize();
return true;
}
export async function reset() {
return BabylonModule.resetView();
}
I found that every function in Napi:: crashes with memory violation error.
I tested by copying lines of Napi::Attach to BabylonNative.cpp then it does not crash.
Can someone on @BabylonNative check my modified JsRuntimeHost repo and what went wrong there?
EDIT: I also tried with original JsRuntimeHost(uses Chakra) and it throws assertion failure.
Can you give a bit more context to what you are trying to do with JsRuntimeHost? Why are you modifying it?
Since Napi::Attach in BabylonNative.cpp requires <napi/env.h> at Node-API-JSI, but original JsRuntimeHost sets NAPI_JAVASCRIPT_ENGINE to Chakra, so I modified to JSI and copied files of Node-API-JSI folder to Node-API folder.
I found that I forgot to implement codegen, which is necessary for new arch’s TurboModules/Fabric Components. once implemented, the app doesn’t crash.
Still working on Fabric Component to render though…
Sorry, I still don’t understand. The Napi::Attach call in Babylon React Native is using JsRuntimeHost configured to use the JSI. Is there something that doesn’t work with this approach?
I had to recompile BabylonNative for Win32, since React Native new arch(which is WinUI 3 app) requires.
If I build for Win32, JsRuntimeHost automatically chooses Chakra, not JSI, so I had to modify it.
And for new arch, there’s a tool named Codegen. but Codegen for React Native Windows seems to not support package which contains both Module and UI component, so we should split @babylonjs/react-native-windows by BabylonModule and EngineView.
How are you building BabylonNative? The JS engine to use is configurable. I don’t understand why you need to modify JsRuntimeHost itself.
Oh, how can I configure JS engine to use?
I just edited CmakeLists.txt to use my repo and built it.
I’m not sure in what context your build is in, but you need to pass a CMake define to CMake setting NAPI_JAVASCRIPT_ENGINE=JSI.
Yup, I already did that on my repo.
Since after implementing codegen, app does not bangs, so it seems ok for JsRuntimeHost now.
Um, I splitted packages and app now crushes again.
even if I used default JsRuntimeHost (not mine), It bangs on same line:
inline Value Object::getProperty(Runtime& runtime, const String& name) const {
return runtime.getProperty(*this, name); // `this` is 0x1
}
And this is call stack:
BabylonModule.dll!facebook::jsi::Runtime::getPointerValue(const facebook::jsi::Pointer & pointer) line 81
BabylonModule.dll!winrt::Microsoft::ReactNative::JsiAbiRuntime::AsJsiObjectRef(const facebook::jsi::Object & obj) line 817
BabylonModule.dll!winrt::Microsoft::ReactNative::JsiAbiRuntime::getProperty(const facebook::jsi::Object & obj, const facebook::jsi::String & name) line 515
BabylonModule.dll!facebook::jsi::Object::getProperty(facebook::jsi::Runtime & runtime, const facebook::jsi::String & name) line 94
BabylonModule.dll!facebook::jsi::Object::getProperty(facebook::jsi::Runtime & runtime, const char * name) line 90
BabylonModule.dll!facebook::jsi::Object::getPropertyAsObject(facebook::jsi::Runtime & runtime, const char * name) line 174
BabylonModule.dll!facebook::jsi::Object::getPropertyAsFunction(facebook::jsi::Runtime & runtime, const char * name) line 188
BabylonModule.dll!napi_env__::napi_env__(facebook::jsi::Runtime & rt) line 51
BabylonModule.dll!Napi::Attach(facebook::jsi::Runtime & rt) line 7
BabylonModule.dll!BabylonNative::ReactNativeModule::ReactNativeModule(facebook::jsi::Runtime & jsiRuntime, std::function<void __cdecl(std::function<void __cdecl(void)>)> jsDispatcher) line 42
Can anyone of @BabylonNative may check my packages?
You can test by following these steps in Windows:
npx @react-native-community/cli init testPackage && cd testPackageyarn add react-native-windowsyarn react-native init-windows --template cpp-app --overwriteyarn add @babylonjs/core @babylonjs/react-native@https://github.com/jihoobyeon/BRN-windows.git#main @babylonjs/react-native-windows-module@https://github.com/jihoobyeon/BRN-windows.git#module @babylonjs/react-native-windows-view@https://github.com/jihoobyeon/BRN-windows.git#viewyarn react-native autolink-windows- Edit
App.tsxas simple BabylonReactNative app andyarn react-native run-windows
UPDATE: It seems to be problem on JSI for Windows, not BabylonNative - since the crash line is located on JSI part, and BRN works without any problem on macOS.
So I raised an issue at RNW, and they assigned it to Mr. Morozov, but I didn’t received any response from him for 3 days.
I guess he must be busy nowdays, but we cannot wait forever with this one issue…
Since I’m at different timezone with Mr. Morozov, (I’m in South Korea and Github profile tells me he is at Redmond, US) It seems to be hard to directly contact him by myself, and it may be discourtesy to urge it to a man looks quite busy.
@bghgary, you’re Microsoft employee too, right? are you located at Pacific timezone?
I know you’re also busy person, and I don’t know how the messenger inside Microsoft internal system works, but I’d like to take the liberty of asking to you could check Mr. Morozov’s status and tell him to inspect this issue.
1 Like
I messaged Vlad earlier and he has responded in the issue you filed.
2 Likes