Unity 2023.1.22f1 Cesium Android Crash

Your_RainBoy · December 11, 2025, 7:59pm

2025/12/11 21:55:38.524 10654 10718 Error Unity InvalidCastException: Unable to cast object of type ‘NativeArray`1’ to type ‘MeshCollider’.
2025/12/11 2

tombstone_00.zip (91.3 KB)

Summary

1:55:39.654 10654 10718 Error CRASH *** 2025/12/11 21:55:39.654 10654 10718 Error 2025/12/11 21:55:39.654 10654 10718 Error 2025/12/11 21:55:39.654 10654 10718 Error 2025/12/11 21:55:39.654 10654 10718 Error 2025/12/11 21:55:39.654 10654 10718 Error 2025/12/11 21:55:39.654 10654 10718 Error 2025/12/11 21:55:39.654 10654 10718 Error 2025/12/11 21:55:39.654 10654 10718 Error 2025/12/11 21:55:39.654 10654 10718 Error 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.654 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH 2025/12/11 21:55:39.655 10654 10718 Error CRASH *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
CRASH Version ‘2023.1.22f1 (c1416845ad01)’, Build type ‘Release’, Scripting Backend ‘il2cpp’, CPU ‘arm64-v8a’, Stripping ‘Enabled’
CRASH Build fingerprint: ‘oculus/eureka/eureka:14/UP1A.231005.007.A1/51563850136800520:user/release-keys’
CRASH Revision: ‘0’
CRASH ABI: ‘arm64’
CRASH Timestamp: 2025-12-11 21:55:39.654613793+0200
CRASH pid: 10654, tid: 10718, name: UnityMain >>> com.bowie.earthquest <<<
CRASH uid: 10162
CRASH signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr --------
CRASH Cause: null pointer dereference
x0 00000077db9bfbc0 x1 000000784432ee08 x2 b400007596766800 x3 b4000075c71f9720
x4 b4000076c3d0c300 x5 000000784432f490 x6 7369784170556674 x7 000000784432f72b
x8 0000000000000001 x9 0000000000000001 x10 0000000000000001 x11 0000000000000001
x12 00000000f0f0f0f1 x13 0000000000000000 x14 000000784432f788 x15 000000784432f7a8
x16 00000077db675aa8 x17 00000078fdb97a70 x18 0000000000000000 x19 00000077a0b5db60
x20 0000000000000000 x21 0000000000000000 x22 00000077db9bf868 x23 0000000000000000
x24 b4000075c71f9720 x25 b4000076c3d0c4f8 x26 0000007844330d40 x27 b400007596766940
x28 0000007844330d40 x29 000000784432eee0
lr 00000077d85293c0 sp 000000784432ee20 pc 00000077d8529424 pst 0000000060001000
CRASH backtrace:
#00 pc 0000000002366424 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libil2cpp.so (BuildId: c45e07b69f834890)
#01 pc 000000000234209c /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libil2cpp.so (BuildId: c45e07b69f834890)
#02 pc 000000000279d2f4 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libil2cpp.so (BuildId: c45e07b69f834890)
#03 pc 0000000001fbf584 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libil2cpp.so (BuildId: c45e07b69f834890)
#04 pc 000000000086a614 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libCesiumForUnityNative-Runtime.so (DotNet::System::Array1DotNet::UnityEngine::Mesh::operator const+60) (BuildId: 9a57eaad269eadfc2223626dcd7912bc44084864)
#05 pc 0000000000f1152c /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libCesiumForUnityNative-Runtime.so (std::__ndk1::__function::__func<CesiumForUnityNative::UnityPrepareRendererResources::prepareInMainThread(Cesium3DTilesSelection::Tile&, void*)::$_4, std::__ndk1::allocator<CesiumForUnityNative::UnityPrepareRendererResources::prepareInMainThread(Cesium3DTilesSelection::Tile&, void*)::$_4>, void (CesiumGltf::Model const&, CesiumGltf::Node const&, CesiumGltf::Mesh const&, CesiumGltf::MeshPrimitive const&, glm::mat<4ul, 4ul, double, (glm::qualifier)0> const&)>::operator()(CesiumGltf::Model const&, CesiumGltf::Node const&, CesiumGltf::Mesh const&, CesiumGltf::MeshPrimitive const&, glm::mat<4ul, 4ul, double, (glm::qualifier)0> const&)+100) (BuildId: 9a57eaad269eadfc2223626dcd7912bc44084864)
#06 pc 00000000011c86c4 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libCesiumForUnityNative-Runtime.so (void CesiumGltf::(anonymous namespace)::forEachPrimitiveInNodeObject<std::__ndk1::function<void (CesiumGltf::Model const&, CesiumGltf::Node const&, CesiumGltf::Mesh const&, CesiumGltf::MeshPrimitive const&, glm::mat<4ul, 4ul, double, (glm::qualifier)0> const&)> >(glm::mat<4ul, 4ul, double, (glm::qualifier)0> const&, CesiumGltf::Model const&, CesiumGltf::Node const&, std::__ndk1::function<void (CesiumGltf::Model const&, CesiumGltf::Node const&, CesiumGltf::Mesh const&, CesiumGltf::MeshPrimitive const&, glm::mat<4ul, 4ul, double, (glm::qualifier)0> const&)>&)+812) (BuildId: 9a57eaad269eadfc2223626dcd7912bc44084864)
#07 pc 00000000011c8218 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libCesiumForUnityNative-Runtime.so (CesiumGltf::Model::forEachPrimitiveInScene(int, std::__ndk1::function<void (CesiumGltf::Model const&, CesiumGltf::Node const&, CesiumGltf::Mesh const&, CesiumGltf::MeshPrimitive const&, glm::mat<4ul, 4ul, double, (glm::qualifier)0> const&)>&&) const+396) (BuildId: 9a57eaad269eadfc2223626dcd7912bc44084864)
#08 pc 0000000000ef4d0c /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libCesiumForUnityNative-Runtime.so (CesiumForUnityNative::UnityPrepareRendererResources::prepareInMainThread(Cesium3DTilesSelection::Tile&, void*)+916) (BuildId: 9a57eaad269eadfc2223626dcd7912bc44084864)
#09 pc 0000000000f3c454 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libCesiumForUnityNative-Runtime.so (Cesium3DTilesSelection::TilesetContentManager::finishLoading(Cesium3DTilesSelection::Tile&, Cesium3DTilesSelection::TilesetOptions const&)+580) (BuildId: 9a57eaad269eadfc2223626dcd7912bc44084864)
#10 pc 0000000000f308f4 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libCesiumForUnityNative-Runtime.so (Cesium3DTilesSelection::Tileset::_processMainThreadLoadQueue()+148) (BuildId: 9a57eaad269eadfc2223626dcd7912bc44084864)
#11 pc 0000000000f2fc38 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libCesiumForUnityNative-Runtime.so (Cesium3DTilesSelection::Tileset::updateView(std::__ndk1::vector<Cesium3DTilesSelection::ViewState, std::__ndk1::allocatorCesium3DTilesSelection::ViewState > const&, float)+1056) (BuildId: 9a57eaad269eadfc2223626dcd7912bc44084864)
#12 pc 000000000088c4b4 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libCesiumForUnityNative-Runtime.so (CesiumForUnityNative::Cesium3DTilesetImpl::Update(DotNet::CesiumForUnity::Cesium3DTileset const&)+152) (BuildId: 9a57eaad269eadfc2223626dcd7912bc44084864)
#13 pc 0000000000843858 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libCesiumForUnityNative-Runtime.so (DotNet_CesiumForUnity_Cesium3DTileset_Update+72) (BuildId: 9a57eaad269eadfc2223626dcd7912bc44084864)
#14 pc 0000000002841d00 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libil2cpp.so (BuildId: c45e07b69f834890)
#15 pc 0000000002363da0 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libil2cpp.so (BuildId: c45e07b69f834890)
#16 pc 0000000002363cec /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libil2cpp.so (BuildId: c45e07b69f834890)
#17 pc 000000000065d634 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libunity.so (BuildId: 96a08cb0836c4aeb)
#18 pc 000000000066cf60 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libunity.so (BuildId: 96a08cb0836c4aeb)
#19 pc 000000000067b584 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libunity.so (BuildId: 96a08cb0836c4aeb)
#20 pc 0000000000499dbc /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libunity.so (BuildId: 96a08cb0836c4aeb)
#21 pc 0000000000562280 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libunity.so (BuildId: 96a08cb0836c4aeb)
#22 pc 00000000005622c0 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libunity.so (BuildId: 96a08cb0836c4aeb)
#23 pc 0000000000562554 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libunity.so (BuildId: 96a08cb0836c4aeb)
#24 pc 00000000006e0024 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libunity.so (BuildId: 96a08cb0836c4aeb)
#25 pc 00000000006fad20 /data/app/~~rT96uuczKtPtrWPx9BN0aQ==/com.bowie.earthquest-F4aGp-_CFqE8Tfs4k4r9JA==/lib/arm64/libunity.so (BuildId: 96a08cb0836c4aeb)
#26 pc 0000000000227440 /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+144) (BuildId: 37be931f63d723c8aafc831096c877fb)
#27 pc 0000000002001254 /memfd:jit-cache (deleted)

Kevin_Ring · December 15, 2025, 9:24am

Hi @Your_RainBoy,

This looks like it falls into the broad category of “AppDomain reload problems.” We’ve made a lot of progress fixing this class of bugs in v1.20.0, and have a PR open that - hopefully! - will eliminate them entirely in the next release. If you want to try the pre-release version with the latter fix, download the “Combined Package” artifact from CI from this PR:

github.com/CesiumGS/cesium-unity

Combine Runtime and Editor assemblies

main ← common-externals

opened 10:39AM - 11 Dec 25 UTC

kring

+719 -722

Wait! Don't close this PR! Sure, it sounds like a terrible idea from the title, …but bear with me... 🐻 Currently, before this PR, we have two managed (AKA .NET) assemblies: CesiumRuntime.dll and CesiumEditor.dll. CesiumEditor contains code that is only ever needed in the Editor, while CesiumRuntime contains... uh.. both runtime and Editor code. Hmm... Well, ok, that's not totally crazy. It's common for a class that is used at runtime to need just a little bit of Editor-specific code for one reason or another. Nothing wrong with that! Ok, so we have a bit of Editor code in our CesiumRuntime assembly, for good reasons. Does that mean the CesiumRuntime assembly is a bit more bloated than it needs to be? No, not at all! The Unity compilation model is funny. Rather than build these two assemblies once and ship them off to end-user systems (which is, arguably, a big reason to used managed code in the first place!), Unity builds them separately in every unique context. So our CesiumRuntime is built once for the Editor on Windows, and again for the Player on Windows (i.e., a built game, no Editor involved). And then again for macOS Editor and again for macOS Player. And again for Android Player (no Editor here). And so on... Ifdef's ensure each platform's build gets exactly what it needs and nothing more. All of which is a long-winded way of explaining why the separation of our code into CesiumRuntime and CesiumEditor is completely pointless, even though it seems like a good idea on the surface. The Windows Editor is always going to load its own specific builds of both CesiumRuntime and CesiumEditor. So why separate them? Well, there is one reason: in the case where an entire file is only suitable for use in the Editor, we can just put it in an Editor specific folder and we're done. No need to ifdef-out the whole file for the Editor. So that's kind of nice. But what's the cost? It turns out it's quite high, because of Reinterop and because of runtime libraries. Let's talk about runtime libraries first. When building applications for Windows, you have to [choose](https://learn.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time-library?view=msvc-170) between the "DLL" runtime library (`/MD`) or the "static" runtime library (`/MT`). If you use the DLL version, then end-users of your application will need to have the MSVC [redistributable](https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170) installed. And it has to be the same or later version as the one paired with the compiler you used to compiler your application, or else things can go very poorly (crashes). Unlike Unreal Engine, Unity doesn't install an MSVC redistributable (I'm talking about the engines themselves here, not our plugins). So we have no guarantees about what version will exist on end-user systems, or we may even find that none exists at all. Forcing our developer users to install one on their end-user systems, when Unity itself does not require this, would not be very nice. So to avoid this, we use the static version of the runtime library. Using the static runtime library means, in turn, that every DLL we build gets its own separate heap. Allocating an object with `new` in one DLL and then `delete`'ing it in another leads to undefined behavior. That means we have to be extraordinarily careful about what we pass between our DLLs. Certainly STL containers are right out. Really, we'd have to be so careful that this really isn't practical to do at all. Which brings us to Reinterop. Reinterop is a plugin for the Roslyn C# compiler that runs while it is compiling the code in the CesiumRuntime and CesiumEditor assemblies. Because these two assemblies are compiled separately, Reinterop generates completely separate code for a corresponding native DLL for each. Changing this would be pretty challenging. The managed CesiumEditor assembly is allowed to call into the managed CesiumRuntime assembly. But because we're using the static version of the MSVC runtime library, it's not safe for the native DLL paired with CesiumEditor to call into the native DLL paired with CesiumRuntime. This is why we currently have a `native~/Shared` folder with a bunch of code that is duplicated between the two native DLLs. And why each has its very own AsyncSystem. And why the network request cancelation implemented in #632 does not also cancel Editor network requests, such as the request to refresh the list of Cesium ion assets, potentially leading to some lingering instability on AppDomain reload. I set out to fix that last point, and this PR is the result. My conclusion was that the least painful approach is to combine CesiumRuntime and CesiumEditor into a single managed assembly, paired with a single Reinterop native DLL. This required a ton of moving stuff around: * Instead of a `CesiumRuntime.dll` built from the `Runtime` directory and a `CesiumEditor.dll` built from the `Editor` directory, there's now just a top level `Source` directory that builds to `CesiumForUnity.dll`. * The top-level `Source` directory has `Runtime` and `Editor` subdirectories, but these are just for organization. They could all be flattened into one directory and that wouldn't change anything. * `#if UNITY_EDITOR` has been added to the top of every file in the `Editor` directory. If this were a normal csproj build system, we could probably make this happen automatically. But Unity asmdefs aren't as sophisticated, so we have to do it manually. * Similarly, `native~` now has a `src` directory with `Editor` and `Runtime` subdirectories. Why `src` here and `Source` for the managed stuff? Just managed versus native conventions, I guess. * The `native~/src/Editor` is automatically excluded if `UNITY_EDITOR` is not defined, because that's easy to do in our native code's cmake build system. So this is probably the simplest 427 file PR that you'll ever review. But there are a lot of moving parts that all have to line up perfectly, and it took me a lot of iterations on CI to get it right. I've tested the Editor on Windows and macOS, and built games on Windows, macOS, Android, and Web. I've also successfully generated an Xcode project for iOS but can't currently build it for unrelated reasons. I didn't try UWP. I don't expect any problems, but should probably try it anyway.

Your_RainBoy · December 15, 2025, 2:16pm

Thank you!!

I really appreciate it!

Can you please explain how one would try the “Combined Package” artifact?
Haven’t been able to figure it out myself.

Thanks again!

Your_RainBoy · December 15, 2025, 8:30pm

By the way, this did not happen in the editor.

Kevin_Ring · December 16, 2025, 7:36am

Ah ok, if it didn’t happen in the Editor, then I’m probably wrong about it being AppDomain related. Now that I’m looking a bit closer at your call stack, it is quite a strange one. There’s no legitimate reason I can think of that we would attempt to cast a NativeArray to a MeshCollider. It points to a rather serious problem, like perhaps some memory corruption.

I remember from previous posts that you’re using an older release, and perhaps some of your own customizations as well. So it’s worth seeing if you can reproduce this in an official release. Especially a recent version.

If you want to try a build from that pull request, though, you can do this:

Download the Combined Package artifact from the second link I posted above.
Extract the .zip file. It should contain a single .tgz file.
Use the Unity Package Manager to add the .tgz file as a Unity package.
Restart the Editor to make sure the new version is picked up (especially the native code).
Build your app for the target platform.

Your_RainBoy · December 16, 2025, 3:31pm

Thank you!

My fork is basically 1.9.0, there are no meaningful changes that you need
to consider, only small commits from newer versions. So I’m dedicated to
applying any changes necessary.

As said before, Cesium for Unity versions later than 1.10.0 or 1.9.0
dramatically lower performance on standalone Android, getting as low as
10-15x worse frame-rates, and I am in no way aware of how a newer version
could help debug.

This also applies to the currently most up to date Cesium version, not just
“newer ones”.

And for my purposes, each frame is incredibly valuable in VR, so even if
performance was just 10% worse (not 10x), it would still not be an option.

I know as a developer you need to value the current versions first and
foremost, but you also have to value your clients’ experience.

I trust you know what is best either way, I’m just here to report this
crash.

Could it just be corrupt memory? Sometimes crashes never occur even in 2h+
sessions.

Kevin_Ring · December 29, 2025, 9:42am

I understand, but as an open source project maintained by a relatively small team, we can’t invest a lot of time trying to track down problems in old versions. Regarding v1.9, the best I can say is, “I don’t know what’s going on there, but we’ve fixed a lot of problems since then and this could very well be one of them.”

If there’s a performance regression since v1.9, I’m not aware of it, but I’m interested in solving it if so! Does this only show up on Android? Or have you noticed newer versions to be slower on other platforms as well?

Your_RainBoy · December 29, 2025, 10:05am

Thank you for understanding!

I think it might actually be post 1.10.0 or 1.11.0, I went with 1.9.0 just
to be sure.

I know it’s on Android, but we’re in the same boat regarding time, so I’m
not yet fully sure it persists on other platforms.

Topic		Replies	Views
Crash in Cesium for Unity during code reloading Cesium for Unity	7	576	August 14, 2024
Editor crash issue with cesium for unity package 1.15.4 Cesium for Unity	11	173	March 29, 2025
CesiumForUnityNative error on vanilla setup!? Cesium for Unity	16	489	November 21, 2023
Unity 6 crashing Cesium for Unity	8	168	November 10, 2025
Cesium v1.27.1 UE5.1.1 Oculus Branch v54.1 Crashing when we open a Cesium URL Cesium for Unreal	5	636	June 27, 2023

Unity 2023.1.22f1 Cesium Android Crash

Related topics