{"id":5093,"date":"2026-03-14T01:21:30","date_gmt":"2026-03-14T01:21:30","guid":{"rendered":"https:\/\/172-234-197-23.ip.linodeusercontent.com\/?page_id=5093"},"modified":"2026-03-14T01:21:30","modified_gmt":"2026-03-14T01:21:30","slug":"dev-notes-03-14-2026","status":"publish","type":"page","link":"https:\/\/neurosphere-2.tail52f848.ts.net\/wordpress\/?page_id=5093","title":{"rendered":"Dev Notes 03-14-2026"},"content":{"rendered":"\n

In registerModel<\/code>, it’s checking that the pointer type is SHARED<\/code>, then calling registerModelImpl<\/code> with the raw pointer and the Earth geometry’s pointer. The issue is that
NativeGeometryModel.getPointer()<\/code> extracts the raw pointer from the wrapped Earth model, but if the original getEarth<\/code> JNI call returned a null pointer, then we’d have a null
pointer object that would throw an NPE when accessing .raw<\/code>. The registerModel<\/code> call appears to be wrapped in some kind of synchronization or validation, so I need to see how that
protection works. So the ReflectInterop is catching the entire exception from ProjectionFactory.<clinit><\/code>, which means the NPE actually escaped from that initialization rather
than being contained within a JNI call. The stack trace shows the error originates in getPointer()<\/code> when trying to access the raw<\/code> field on a null Pointer<\/code> object during
ProjectionFactory<\/code> class initialization.<\/p>\n\n\n\n

Looking at the sequence more carefully though\u2014the FATAL error is being logged at line 563 in GLMapView.<init><\/code>, not 557, and it’s showing as an NPE rather than an
ExceptionInInitializerError<\/code>. That suggests something else is happening at that later line that’s triggering a different exception. where ProjectionFactory<\/code> is first accessed. The
ExceptionInInitializerError from line 557 is caught somewhere! Then at line 563, MapSceneModel<\/code> is constructed with ProjectionFactory.getProjection(4326)<\/code> which now returns null
(since the static init failed, any future call throws ExceptionInInitializerError which might be caught, or maybe the class partially initialized\u2026).<\/p>\n\n\n\n

Actually, looking at the stack trace again:<\/p>\n\n\n\n

  at com.atakmap.map.MapSceneModel.<init>(MapSceneModel.java:72)\n  at com.atakmap.map.opengl.GLMapView.<init>(GLMapView.java:563)<\/code><\/pre>\n\n\n\n
The NPE is projection.getSpatialReferenceID()<\/code> where projection is null. So ProjectionFactory.getProjection(4326)<\/code> returned null.<\/p>\n\n\n\n
But that doesn’t make sense\u2014if the static initializer threw an exception, the JVM should permanently mark the class as broken and throw ExceptionInInitializerError on any subsequent
access. Unless\u2026 the exception is being caught somewhere, maybe in ReflectInterop or wrapped in a try-catch block. Let me check if there’s error handling around that line 557 call
in GLMapView’s constructor that’s swallowing the exception and allowing execution to continue.<\/p>\n\n\n\n
So the ReflectInterop warnings are from registerModelImpl<\/code> calling back into Java via JNI, catching an NPE internally and logging it as a warning. The static initializer actually
succeeds (the exception doesn’t escape), but the model gets registered with a null pointer. Then when getProjectionImpl<\/code> is called, it returns null because the model wasn’t
properly initialized, causing the NPE in MapSceneModel when trying to call methods on the null projection object.<\/p>\n\n\n\n
The real fix is to make sure getProjectionImpl<\/code> returns a valid Projection object for SRID 4326. Since getProjectionImpl<\/code> is a native method that returns a Projection interface
object, I need to understand how JNI handles returning Java objects from C++ code.<\/p>\n\n\n\n
I can create an EquirectangularMapProjection<\/code> instance through JNI by finding the class, getting its constructor, and instantiating it. This approach is clean since
EquirectangularMapProjection<\/code> extends AbstractProjection<\/code> which implements the Projection<\/code> interface, so it satisfies the return type requirement.<\/p>\n\n\n\n
The same pattern applies for ECEFProjection<\/code> with SRID 4978. For the NativeGeometryModel.getPointer()<\/code> issue, the real problem is that getEarth()<\/code> returns a null pointer, but
ReflectInterop<\/code> catches the resulting NPE and passes 0 as the earth pointer to registerModelImpl<\/code>, which should work fine anyway.<\/p>\n\n\n\n
The key fix is implementing getProjectionImpl<\/code> to return a Java EquirectangularMapProjection<\/code> for SRID 4326, which will properly support the getSpatialReferenceID()<\/code> call in
MapSceneModel<\/code>. I need to check whether MapSceneModel<\/code> makes any JNI calls on the projection object itself.<\/p>\n\n\n\n
\u25cf Two problems clear now:<\/p>\n\n\n\n
    \n
  1. NativeGeometryModel.getPointer(model.earth) NPE because getEarth stub returns null \u2014 caught by ReflectInterop as warning<\/li>\n\n\n\n
  2. getProjectionImpl(4326) JNI stub returns null \u2192 MapSceneModel.:72 NPE The fix: implement getProjectionImpl to return a real Java EquirectangularMapProjection instance, and getEarth to return a non-null Pointer:<\/li>\n<\/ol>\n\n\n\n
    \u25cf Read MapSceneModel constructor and registerModel
    $
    ATAK_SRC=\/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main<\/p>\n\n\n\n
    echo “=== MapSceneModel constructor (critical path lines 60-130) ===”
    find “$ATAK_SRC\/takkernel” -name “MapSceneModel.java” | head -1 | xargs -I{} sed -n ‘60,140p’ {}\u2026
    \u2514 288 lines\u2026<\/p>\n\n\n\n
    \u25d0 Now I understand the full picture:<\/p>\n\n\n\n
      \n
    1. EquirectangularMapProjection.DISPLAY_MODEL = MapProjectionDisplayModel.createDefaultLLAPlanarModel(4326)<\/code> creates a MapProjectionDisplayModel<\/code> using the Java constructor with
      DEFAULT_PLANE<\/code> (a pure Java Plane<\/code> object). This is NOT a JNI call – createDefaultLLAPlanarModel<\/code> is a Java method!<\/li>\n\n\n\n
    2. Inside MapProjectionDisplayModel(int srid, GeometryModel earth, ...)<\/code> constructor:\n
        \n
      • GeometryModel_interop.getPointer(earth)<\/code> – gets the native pointer of the Plane<\/code> object<\/li>\n\n\n\n
      • Since Plane<\/code> isn’t a NativeGeometryModel<\/code>, getPointer<\/code> returns 0, triggering the JNI wrap<\/code> call which returns a shared pointer \u2713<\/li>\n\n\n\n
      • this.pointer<\/code> gets set to that shared pointer<\/li>\n<\/ul>\n<\/li>\n\n\n\n
      • When registerModel(model)<\/code> is called, the pointer type check passes and registerImpl<\/code> is invoked with the shared pointer.
        • This makes a JNI call to registerModelImpl<\/code>, which internally tries to get the pointer for model.earth<\/code> (the DEFAULT_PLANE<\/code>)<\/li>
        • Since Plane<\/code> isn’t a NativeGeometryModel<\/code>, getPointer<\/code> would return 0 again, but I need to verify what the actual getPointer<\/code> implementation does in this case.<\/li><\/ul>Actually, looking at the stack trace more carefully\u2014the NPE is happening when trying to read the .raw<\/code> field from a null Pointer<\/code> object. This means the NativeGeometryModel<\/code>
          instance itself exists, but its pointer<\/code> field is null. So somewhere a NativeGeometryModel<\/code> was created without properly initializing its pointer. The issue traces back to GeometryModel_interop.create()<\/code> being called with a null pointer from getEarth(pointer.raw)<\/code>, which then creates a NativeGeometryModel<\/code> with a null
          pointer field. When getPointer()<\/code> is later called on this model, it tries to access .raw<\/code> on that null pointer and crashes. I need to figure out which constructor path is creating
          this uninitialized model\u2014either the one that uses GeometryModel_interop.getPointer()<\/code> on the earth parameter, or something else. Looking at the createDefaultLLAPlanarModel<\/code> path, it uses the first constructor with DEFAULT_PLANE<\/code> directly, so it doesn’t go through getEarth()<\/code>. That means the NPE must be
          coming from the second constructor path where GeometryModel_interop.create()<\/code> is called. The real question is what happens when the native registerImpl<\/code> method tries to access
          model.earth<\/code> through reflection\u2014since model.earth<\/code> is a Plane<\/code> object, not a NativeGeometryModel<\/code>, the reflection call might be failing or returning something unexpected. The NPE message “on a null object reference” suggests something tried to access .raw<\/code> on a null object, which means there’s a NativeGeometryModel<\/code> instance somewhere with a null
          .pointer<\/code> field. I’m thinking GeometryModel_interop.getPointer()<\/code> is being called on the Plane<\/code> object through reflection, and that’s where things are breaking down\u2014either it’s
          not finding the right method or it’s returning null instead of a valid pointer. Looking at the wrap<\/code> JNI call in the constructor, if getPointer<\/code> returns 0 for non-native objects, then this.pointer = wrap(srid, earth, ...)<\/code> gets called with that 0 value, and
          the stub returns a shared pointer. But I need to trace through whether wrap<\/code> is actually returning null somewhere, or if the reflection call itself is failing and leaving the
          pointer uninitialized. The real issue might be in registerImpl<\/code> \u2014 when it tries to access model.earth<\/code> through reflection, it’s still getting the DEFAULT_PLANE<\/code> object, and then calling getPointer<\/code> on
          that. Since Plane<\/code> isn’t a NativeGeometryModel<\/code>, the getPointer<\/code> method\u2026 Checking the actual implementation\u2026 Wait, I’m overthinking this. The ReflectInterop warning is just a side effect \u2014 the actual fatal error happens later when MapSceneModel<\/code> tries to call
          projection.getSpatialReferenceID()<\/code> but projection<\/code> is null. So even though something fails during ProjectionFactory<\/code> initialization, the class still loads successfully, and then
          when we try to get a projection, we hit the null pointer. The fix is straightforward: I need to make getProjectionImpl<\/code> return an actual Projection<\/code> object instead of null. For SRID 4326, I should return an EquirectangularMapProjection<\/code>
          instance. But I need to verify that this Java implementation will work correctly with MapSceneModel<\/code> \u2014 specifically, that it properly implements getSpatialReferenceID()<\/code>. Writing
          JNI code\u2026 Now I’m thinking through how MapSceneModel<\/code> uses the projection once it’s instantiated\u2014it takes the projection object along with display parameters like DPI, dimensions, focus
          point, and camera settings to initialize the scene model in the takkernel library.<\/li>\n<\/ol>\n\n\n\n
          \u25cf Now I have the full picture. The fix:<\/p>\n\n\n\n
            \n
          1. ProjectionFactory.getProjectionImpl(4326) JNI stub returns null \u2014 need to return a real EquirectangularMapProjection Java instance<\/li>\n\n\n\n
          2. The ReflectInterop NPE in registerImpl is a caught warning (non-fatal) Let me check com.atakmap.map.MapSceneModel line 72:<\/li>\n<\/ol>\n\n\n\n
            \u25cf Check MapSceneModel constructor and ECEFProjection
            $
            ATAK_SRC=\/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main<\/p>\n\n\n\n
            echo “=== com.atakmap.map.MapSceneModel lines 60-120 ===”
            find “$ATAK_SRC\/takkernel” -name “MapSceneModel.java” -path “\/atakmap\/map\/<\/em>” | head -1 | xargs -I{} sed -n ‘1,20p’ {}\u2026
            \u2514 149 lines\u2026<\/p>\n\n\n\n
            \u25d0 Now I see the full picture. The com.atakmap.map.MapSceneModel<\/code> constructor calls create(...)<\/code> which is a JNI method returning a Pointer<\/code>. Our auto-stub for
            Java_com_atakmap_map_MapSceneModel_create<\/code> returns makeSharedPointer(env, 1L)<\/code>.<\/p>\n\n\n\n
            Then init()<\/code> calls getProjection(this.pointer.raw)<\/code> \u2192 JNI, which returns a srid. Our stub returns 0. Then ProjectionFactory.getProjection(0)<\/code> \u2192 getProjectionImpl(0)<\/code> \u2192 returns
            null.<\/p>\n\n\n\n
            Then this.mapProjection = null<\/code>. But the outer gov.tak.api.engine.map.MapSceneModel<\/code> in GLMapView is constructing with ProjectionFactory.getProjection(4326)<\/code>, which also returns
            null from our stub, so that’s passing null where a projection is expected.<\/p>\n\n\n\n
            Looking at the takkernel MapSceneModel<\/code> constructor, it immediately calls proj.getSpatialReferenceID()<\/code> on that null reference, causing an NPE. The fix is to have
            getProjectionImpl(4326)<\/code> return an actual EquirectangularMapProjection<\/code> instead of null.<\/p>\n\n\n\n
            But then there’s another layer: the MapSceneModel<\/code> constructor delegates to a JNI create()<\/code> method that returns a pointer, and during initialization it tries to fetch the display
            model by calling getProjection()<\/code> on that pointer, which our stub returns 0 for, leading to another null dereference downstream.<\/p>\n\n\n\n
            Tracing through the initialization chain, the JNI stubs are returning zeros and null pointers across the board\u2014getWidth<\/code> and getHeight<\/code> both return 0,
            ProjectionFactory.getProjection(0)<\/code> returns null, and the matrix operations are creating NativeMatrix<\/code> wrappers around the stub pointers, which might actually work but the whole
            thing is built on a foundation of mock data.<\/p>\n\n\n\n
            The real issue is that MapSceneModel<\/code> is being instantiated with a null projection, and when it tries to call proj.getSpatialReferenceID()<\/code> at line 72, it crashes. The projection
            comes from ProjectionFactory.getProjection(4326)<\/code>, so I need to make sure getProjectionImpl(4326)<\/code> actually returns a valid EquirectangularMapProjection<\/code> instead of null. Looking
            at the MapSceneModel<\/code> constructor call chain through create()<\/code>, it’s passing through a series of parameters like DPI, dimensions, spatial reference ID, coordinates, and camera
            settings.<\/p>\n\n\n\n
            Now tracing through the initialization, the JNI stub returns a valid pointer, but then when init()<\/code> tries to fetch the projection using that ID, it gets null back from the JNI
            layer, which cascades into ProjectionFactory.getProjection(0)<\/code> returning null. The issue is that the outer gov.tak<\/code> version of MapSceneModel<\/code> also depends on having a valid
            projection to initialize properly, so if the inner implementation’s mapProjection is null, it could NPE when trying to access its spatial reference ID.<\/p>\n\n\n\n
            Looking at the actual code, there’s a null check that prevents the NPE\u2014if _impl.mapProjection<\/code> is null, then this.mapProjection<\/code> just stays null too. That’s fine for now, though
            ATAK’s render code will eventually try to use it and might fail there.<\/p>\n\n\n\n
            The immediate solution is to implement getProjectionImpl<\/code> to return the right projection types based on the spatial reference ID\u2014EquirectangularMapProjection<\/code> for 4326 and
            ECEFProjection<\/code> for 4978. Then I need to look at how MapSceneModel.create()<\/code> returns a pointer and trace through the camera field assignments.<\/p>\n\n\n\n
            The camera’s modelView and projection matrices come from _impl<\/code>, and in the initialization code they’re being wrapped through JNI stubs. The issue is that getForward<\/code> and
            getInverse<\/code> are supposed to return pointers, but our auto-generated stubs are returning null instead of the actual matrix data.<\/p>\n\n\n\n
            When Matrix_interop.create(null, this)<\/code> gets called with a null pointer, it creates a NativeMatrix<\/code> with a null pointer, which will throw a null pointer exception as soon as the
            matrix is actually used.<\/p>\n\n\n\n
            Looking at the stub implementations for getForward<\/code>, getInverse<\/code>, and getCameraProjection<\/code> \u2014 they’re returning null, but they should be returning shared pointers since they’re
            JNI methods that return jobjects. The issue is they don’t match the pattern we use to identify which stubs need to return shared pointers, so they’re not in our MUST_RETURN_SHARED<\/code>
            list. I need to check the actual JNI signatures for MapSceneModel<\/code> to understand what these methods should be returning.<\/p>\n\n\n\n
            Actually, I’m overcomplicating this. The immediate crash is getProjectionImpl(4326)<\/code> returning null, which then gets passed to proj.getSpatialReferenceID()<\/code> on line 72 of
            MapSceneModel.create()<\/code>. Let me fix that first and see what the next error is. I need to examine the exact lines around 563 in GLMapView to understand what’s being instantiated and
            where the null projection is coming from.<\/p>\n\n\n\n
            \u25cf Read GLMapView lines 550-575
            $
            find \/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main -name “GLMapView.java” | head -1 | xargs -I{} sed -n ‘550,575p’ {}<\/p>\n\n\n\n
            \u2514 26 lines\u2026<\/p>\n\n\n\n
            \u25d0 Confirmed. ProjectionFactory.getProjection(4326)<\/code> is called and it returns null. Then new MapSceneModel(..., null, ...)<\/code> \u2192 proj.getSpatialReferenceID()<\/code> \u2192 NPE.<\/p>\n\n\n\n
            The fix: implement Java_com_atakmap_map_projection_ProjectionFactory_getProjectionImpl<\/code> to return an EquirectangularMapProjection<\/code> instance for 4326.<\/p>\n\n\n\n
            Let me also check if ProjectionFactory.getProjection<\/code> can just short-circuit before calling getProjectionImpl<\/code> if the DISPLAY_MODEL is registered. Looking at the earlier code:<\/p>\n\n\n\n
            The method checks the cache first, but if there’s a cache miss, it always calls getProjectionImpl<\/code> regardless. So the native implementation needs to handle SRID 4326 and return a
            valid projection instead of null.<\/p>\n\n\n\n
            Looking at how this projection gets used downstream, MapSceneModel<\/code> receives it and immediately extracts the spatial reference ID to pass into a native constructor, which means the
            projection object needs to be properly initialized before it reaches that point. I’m tracing through what happens when these null pointers get passed
            around\u2014Matrix_interop.create()<\/code> will likely return null or throw an exception when given a null pointer, and then the camera initialization tries to access properties on
            potentially null objects, which could cause issues downstream.<\/p>\n\n\n\n
            The real fix is to make sure getProjectionImpl<\/code> returns the right projection type based on the EPSG code, and ensure the matrix getter methods return actual non-null pointers
            instead of stubs. Continuing to trace through the interop layer, the create<\/code> method checks if the pointer is null or invalid and returns null if so. This means when our stubs
            return nullptr for those camera matrix methods, the interop creates null references, which then propagate through to leave _impl.camera.modelView<\/code> and _impl.camera.projection<\/code> as
            null values in the initialization chain.<\/p>\n\n\n\n
            Rather than keep chasing through all these layers, I should just fix the immediate NPE in getProjectionImpl<\/code> and mark a broader set of methods as needing to return SHARED pointers
            instead of raw ones.<\/p>\n\n\n\n
            Now I’m looking at how Matrix_interop.create()<\/code> handles null pointers to understand what happens when we pass null instead of a valid pointer.<\/p>\n\n\n\n
            \u25cf Read Interop.create and NativeMatrix
            $
            ATAK_SRC=\/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main
            echo “=== Interop.java create method ===”
            find “$ATAK_SRC” -name “Interop.java” | head -1 | xargs cat 2>\/dev\/null | grep -A20 “public T create”\u2026
            \u2514 52 lines\u2026<\/p>\n\n\n\n
            \u25cf Check ReflectInterop.create behavior with null
            $
            ATAK_SRC=\/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main
            # Find the actual Interop implementation (ReflectInterop)
            find “$ATAK_SRC” -name “ReflectInterop.java” | head -1 | xargs sed -n ‘1,80p’ 2>\/dev\/null\u2026
            \u2514 9 lines\u2026<\/p>\n\n\n\n
            \u25cf Read com.atakmap.interop.Interop
            $
            ATAK_SRC=\/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main
            find “$ATAK_SRC” -name “Interop.java” -path “\/atakmap\/interop\/<\/em>” | head -1 | xargs sed -n ‘1,120p’ 2>\/dev\/null<\/p>\n\n\n\n
            \u2514 121 lines\u2026<\/p>\n\n\n\n
            \u25d0 OK so Interop.create(pointer, owner)<\/code> is abstract – it’s implemented by a concrete class registered via registry<\/code>. The ReflectInterop<\/code> class must implement this. If pointer<\/code> is
            null, the concrete implementation probably handles it by checking for null.<\/p>\n\n\n\n
            But I don’t need to trace this further. The key insight is:<\/p>\n\n\n\n
              \n
            • Matrix_interop.create(null, this)<\/code> might return null or might NPE depending on the implementation<\/li>\n\n\n\n
            • The important thing is: getForward(1L)<\/code> returns null from our stub \u2192 Matrix_interop.create(null, this)<\/code> likely returns null \u2192 this.forward = null<\/code><\/li>\n\n\n\n
            • Later when the MapSceneModel is used for rendering, accessing this.forward.transform(...)<\/code> would NPE So I need to fix the stub methods to return actual shared pointers instead of null, and also ensure getProjectionImpl(4326)<\/code> returns a real EquirectangularMapProjection<\/code> rather
              than a placeholder. Looking at the JNI method signatures in MapSceneModel.java, I see that getProjection<\/code> returns an int (the SRID), while getForward<\/code>, getInverse<\/code>, getCameraProjection<\/code>, and
              getCameraModelView<\/code> all return Pointers. The current stub for getProjection<\/code> returns 0, which causes ProjectionFactory.getProjection(0)<\/code> to be called downstream and likely
              returns null or an invalid projection. I need to change the stub to return 4326 as the default SRID instead, so that when MapSceneModel.init()<\/code> calls ProjectionFactory.getProjection(getProjection(this.pointer.raw))<\/code>,
              it gets a valid EquirectangularMapProjection rather than null. For the Pointer-returning methods like getForward<\/code> and getInverse<\/code>, I need to check if my regex pattern is matching
              them correctly. Looking at my jni_signatures.txt<\/code>, I can filter by return type \u2014 if ret_type == 'jobject'<\/code>, then I know it returns a Pointer and should be added to the MUST_RETURN_SHARED list.
              This way I can expand the pattern to catch methods like getForward<\/code>, getInverse<\/code>, getCameraProjection<\/code>, and similar getter methods that return objects. and not in the
              MUST_RETURN_SHARED regex, return null. But for MapSceneModel getter methods that return Pointer, they’re jobject<\/code> and not in the pattern. Better approach: add a separate regex pattern for methods that return Pointer (jobject) that are getter methods for native objects, or just add get[A-Z]<\/code> to the pattern for
              MapSceneModel specifically. Actually, the cleanest solution is to add a list of specific method names that need to return non-null Pointer. Once I fix getProjectionImpl<\/code>, the MapSceneModel constructor will work. Then during init()<\/code>, calls like getForward(1L)<\/code> and getInverse(1L)<\/code> will return null, which gets passed
              to Matrix_interop.create()<\/code> and likely returns null, leaving this.forward<\/code> and this.inverse<\/code> as null. This will cause NPEs later in the render loop, but the immediate crash is
              getProjectionImpl<\/code>. Let me fix that first and make getProjection(int)<\/code> return 4326 for MapSceneModel. I need to figure out the JNI signature for MapSceneModel.getProjection(long pointer)<\/code>.<\/li>\n<\/ul>\n\n\n\n
              \u25cf Now I have the full picture. Three fixes needed:<\/p>\n\n\n\n
                \n
              1. getProjectionImpl(4326) \u2192 return Java EquirectangularMapProjection instance<\/li>\n\n\n\n
              2. MapSceneModel.getProjection(long) \u2192 return 4326 (not 0) so mapProjection is populated<\/li>\n\n\n\n
              3. MapSceneModel.getForward\/getInverse\/getCameraProjection\/getCameraModelView \u2192 return SHARED Pointer<\/li>\n<\/ol>\n\n\n\n
                \u25cf Read \/tmp\/takstub\/jni\/tak_engine_stub.cpp lines 330-365
                \u2514 36 lines read<\/p>\n\n\n\n
                \u25cf Edit \/tmp\/takstub\/jni\/tak_engine_stub.cpp (+52)<\/p>\n\n\n\n
                \u25cf Now add the new hand-implemented methods to HAND_IMPL in the Python generator and regenerate to remove them from auto-stubs:<\/p>\n\n\n\n
                \u25cf Regenerate stubs removing new hand-impl methods
                $ python3 << ‘PYEOF’
                import re<\/p>\n\n\n\n
                with open(‘\/tmp\/jni_signatures.txt’) as f:
                lines = [l.strip() for l in f if l.strip()]\u2026
                \u2514 114 lines\u2026<\/p>\n\n\n\n
                \u25cf Splice stubs and rebuild native lib
                $
                # Splice new auto-stubs into tak_engine_stub.cpp
                python3 -c “
                lines = open(‘\/tmp\/takstub\/jni\/tak_engine_stub.cpp’).readlines()
                cut = 0\u2026
                \u2514 27 lines\u2026<\/p>\n\n\n\n
                \u25cf Deploy and test new build
                $
                JNILIBS=\/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main\/atak\/ATAK\/app\/src\/main\/jniLibs\/arm64-v8a
                cp \/tmp\/takstub\/libs\/arm64-v8a\/libtakengine.so “$JNILIBS\/”<\/p>\n\n\n\n
                export JAVA_HOME=\/opt\/amazon-corretto-11.0.30.7.1-linux-x64\u2026
                \u2514 77 lines\u2026<\/p>\n\n\n\n
                \u276f Consider: ‘Nice \u2014 this is exactly the kind of job where a tiny bit of automation saves you from a thousand paper cuts<\/strong>. The idea is:<\/p>\n\n\n\n
                  \n
                1. Scan the ATAK native source for every JNIEXPORT<\/code> function.<\/li>\n\n\n\n
                2. Extract the full function signature.<\/li>\n\n\n\n
                3. Generate a .cpp<\/code> file with stub implementations<\/strong> that compile.<\/li>\n\n\n\n
                4. Return sensible defaults so the JVM doesn\u2019t crash.<\/li>\n\n\n\n
                5. Compile the stub library as libtakengine.so<\/code>. Below is a practical pattern<\/strong> that works well against the ATAK source tree.<\/li>\n<\/ol>\n\n\n\n
                  \n\n\n\n
                  # 1. Directory Layout (example)<\/p>\n\n\n\n
                    ATAK\/\n    takengine\/\n       src\/main\/cpp\/\n            Globe.cpp\n            MapRenderer.cpp\n            DatabaseImpl.cpp\n            ...\n    tools\/\n        generate_jni_stubs.py<\/code><\/pre>\n\n\n\n
                  You run the generator against the native cpp folder<\/strong>.<\/p>\n\n\n\n
                  \n\n\n\n
                  # 2. Python Script: Extract + Generate Stubs<\/p>\n\n\n\n
                  Save as:<\/p>\n\n\n\n
                    tools\/generate_jni_stubs.py<\/code><\/pre>\n\n\n\n
                    import os\n  import re\n\n  SOURCE_DIR = \"..\/takengine\/src\/main\/cpp\"\n  OUTPUT_FILE = \"jni_stubs.cpp\"\n\n  # Regex that captures JNIEXPORT signatures\n  JNI_PATTERN = re.compile(\n      r'(JNIEXPORT\\s+[^\\(]+\\s+JNICALL\\s+[^\\(]+\\([^\\)]*\\))',\n      re.MULTILINE\n  )\n\n  def default_return(signature):\n      \"\"\"Return safe default values based on return type\"\"\"\n      if \"jboolean\" in signature:\n          return \"return JNI_FALSE;\"\n      if \"jint\" in signature:\n          return \"return 0;\"\n      if \"jlong\" in signature:\n          return \"return 0;\"\n      if \"jfloat\" in signature:\n          return \"return 0.0f;\"\n      if \"jdouble\" in signature:\n          return \"return 0.0;\"\n      if \"jobject\" in signature:\n          return \"return nullptr;\"\n      if \"jstring\" in signature:\n          return \"return nullptr;\"\n      if \"void\" in signature:\n          return \"\"\n      return \"return 0;\"\n\n  def extract_signatures():\n      signatures = []\n\n      for root, _, files in os.walk(SOURCE_DIR):\n          for f in files:\n              if f.endswith(\".cpp\") or f.endswith(\".cc\"):\n                  path = os.path.join(root, f)\n\n                  with open(path, \"r\", errors=\"ignore\") as src:\n                      text = src.read()\n\n                      matches = JNI_PATTERN.findall(text)\n                      signatures.extend(matches)\n\n      return signatures\n\n\n  def generate_stub_file(signatures):\n      with open(OUTPUT_FILE, \"w\") as out:\n\n          out.write('#include <jni.h>\\n')\n          out.write('#include <android\/log.h>\\n\\n')\n\n          out.write('#define LOG_TAG \"ATAK_STUB\"\\n\\n')\n\n          for sig in signatures:\n              ret = default_return(sig)\n\n              out.write(f\"{sig} {{\\n\")\n\n              out.write(\n                  '    __android_log_print(ANDROID_LOG_INFO, LOG_TAG, \"Stub called\");\\n'\n              )\n\n              if ret:\n                  out.write(f\"    {ret}\\n\")\n\n              out.write(\"}\\n\\n\")\n\n  def main():\n      sigs = extract_signatures()\n\n      print(f\"Found {len(sigs)} JNI methods\")\n\n      generate_stub_file(sigs)\n\n      print(f\"Generated {OUTPUT_FILE}\")\n\n  if __name__ == \"__main__\":\n      main()<\/code><\/pre>\n\n\n\n
                  \n\n\n\n
                  # 3. Run It<\/p>\n\n\n\n
                    python3 generate_jni_stubs.py<\/code><\/pre>\n\n\n\n
                  Output example:<\/p>\n\n\n\n
                    Found 1048 JNI methods\n  Generated jni_stubs.cpp<\/code><\/pre>\n\n\n\n
                  Takes ~1\u20132 seconds.<\/p>\n\n\n\n
                  \n\n\n\n
                  # 4. Example Generated Stub<\/p>\n\n\n\n
                  Output looks like:<\/p>\n\n\n\n
                    JNIEXPORT jint JNICALL\n  Java_com_atakmap_map_Globe_getFullEquitorialExtentPixels\n  (JNIEnv *env, jclass clazz, jdouble dpi)\n  {\n      __android_log_print(ANDROID_LOG_INFO, \"ATAK_STUB\", \"Stub called\");\n      return 0;\n  }<\/code><\/pre>\n\n\n\n
                  You then replace specific methods manually<\/strong>.<\/p>\n\n\n\n
                  Example:<\/p>\n\n\n\n
                    JNIEXPORT jint JNICALL\n  Java_com_atakmap_map_Globe_getFullEquitorialExtentPixels\n  (JNIEnv *env, jclass clazz, jdouble dpi)\n  {\n      const double R = 6378137.0;\n      const double INCHES_PER_METER = 37.37;\n\n      double circumference = 2.0 * 3.141592653589793 * R;\n      double pixels = circumference * INCHES_PER_METER * dpi;\n\n      return (jint)pixels;\n  }<\/code><\/pre>\n\n\n\n
                  \n\n\n\n
                  # 5. Build the Stub Engine<\/p>\n\n\n\n
                  Minimal CMakeLists.txt<\/code>:<\/p>\n\n\n\n
                    cmake_minimum_required(VERSION 3.10)\n\n  project(takengine_stub)\n\n  add_library(takengine SHARED\n      jni_stubs.cpp\n  )\n\n  find_library(log-lib log)\n\n  target_link_libraries(\n      takengine\n      ${log-lib}\n  )<\/code><\/pre>\n\n\n\n
                  \n\n\n\n
                  # 6. Build with Android NDK<\/p>\n\n\n\n
                    export ANDROID_NDK=$HOME\/Android\/Sdk\/ndk\/25.2.9519653\n\n  cmake \\\n   -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK\/build\/cmake\/android.toolchain.cmake \\\n   -DANDROID_ABI=arm64-v8a \\\n   -DANDROID_PLATFORM=android-21 \\\n   -B build\n\n  cmake --build build<\/code><\/pre>\n\n\n\n
                  Output:<\/p>\n\n\n\n
                    libtakengine.so<\/code><\/pre>\n\n\n\n
                  \n\n\n\n
                  # 7. Drop the Engine Into ATAK<\/p>\n\n\n\n
                  Place it here:<\/p>\n\n\n\n
                    atak\/app\/src\/main\/jniLibs\/arm64-v8a\/libtakengine.so<\/code><\/pre>\n\n\n\n
                  Then build:<\/p>\n\n\n\n
                    .\/gradlew assembleDebug<\/code><\/pre>\n\n\n\n
                  \n\n\n\n
                  # 8. Runtime Debugging<\/p>\n\n\n\n
                  Watch calls in real time:<\/p>\n\n\n\n
                    adb logcat | grep ATAK_STUB<\/code><\/pre>\n\n\n\n
                  You\u2019ll see which JNI methods ATAK hits during startup.<\/p>\n\n\n\n
                  Implement those one by one<\/strong>.<\/p>\n\n\n\n
                  \n\n\n\n
                  # 9. Result<\/p>\n\n\n\n
                  Instead of implementing 1048 JNI methods manually<\/strong>, you now have:<\/p>\n\n\n\n
                    1048 auto-generated stubs\n  +\n  10\u201320 real implementations<\/code><\/pre>\n\n\n\n
                  That\u2019s enough to boot the UI and start inserting the Cesium rendering backend<\/strong>.<\/p>\n\n\n\n
                  \n\n\n\n
                  # 10. Pro Tip (Huge Time Saver)<\/p>\n\n\n\n
                  Modify the generator to create per-class stub files<\/strong>:<\/p>\n\n\n\n
                    jni_globe_stubs.cpp\n  jni_database_stubs.cpp\n  jni_projection_stubs.cpp<\/code><\/pre>\n\n\n\n
                  That makes replacing chunks with real implementations much easier later.<\/p>\n\n\n\n
                  \n\n\n\n
                  If you want, I can also show you a much more advanced version of this generator<\/strong> that:<\/p>\n\n\n\n
                  \u2022 parses JNI signatures directly from compiled .class<\/code> files
                  \u2022 auto-creates matching C++ stubs
                  \u2022 builds a complete libtakengine.so<\/code> automatically<\/p>\n\n\n\n
                  That version can regenerate the entire compatibility layer in under 0.5 seconds<\/strong>. \ud83d\ude80
                  ‘<\/p>\n\n\n\n
                  \u25d0 We’ve crashed frontier advanced! Now the crash is:<\/p>\n\n\n\n
                    java.lang.IllegalArgumentException: left == right\n      at android.opengl.Matrix.orthoM(Matrix.java:447)\n      at com.atakmap.opengl.GLES20FixedPipeline.glOrthof(GLES20FixedPipeline.java:171)\n      at com.atakmap.map.opengl.GLMapView.sync(GLMapView.java:1422)\n      at com.atakmap.map.opengl.GLMapView.<init>(GLMapView.java:572)<\/code><\/pre>\n\n\n\n
                  The issue is that GLMapView.sync()<\/code> is calling glOrthof<\/code> with identical left and right values because our MapSceneModel stub is returning 0 for both width and height, which
                  cascades into the ortho matrix calculation getting zero dimensions.<\/p>\n\n\n\n
                    the scene dimensions. Since width=0 and height=0, it might compute `left=right=0` or similar.\n\n  Let me fix `MapSceneModel.getWidth` and `MapSceneModel.getHeight` to return the actual dimensions... but wait, the stub doesn't know the actual dimensions!\n\n  Actually, looking at the constructor, `width` and `height` are passed as arguments to the `create(...)` JNI call. But our `create` stub ignores them and returns a pointer to fake \n  memory. So `getWidth(1L)` returns 0.\n\n  We need to store the width\/height in our stub's MapSceneModel state and return them from `getWidth`\/`getHeight`. But this is getting complicated...<\/code><\/pre>\n\n\n\n
                  Wait, I need to rewrite this, not copy it. Let me try again:<\/p>\n\n\n\n
                  The issue is that the scene dimensions are coming back as zero, which makes the ortho projection collapse. The MapSceneModel<\/code> constructor receives width and height arguments that
                  get passed to the JNI create<\/code> call, but our stub ignores those values and just returns a fake pointer. So when getWidth<\/code> and getHeight<\/code> are called later, they return 0. I need to
                  make the stub actually store and return those dimension values instead of hardcoding zeros.<\/p>\n\n\n\n
                  The simplest fix is to create a state struct that holds the width, height, and DPI from the create call, then have the getter methods return those stored values.<\/p>\n\n\n\n
                  But I’m realizing the current approach of returning a fixed pointer value (1L) won’t work if multiple MapSceneModel instances are created\u2014they’d all reference the same state. I need
                  to allocate actual memory for each instance and return its address as the pointer, so each one maintains its own independent state.<\/p>\n\n\n\n
                  \u25cf Crash advanced significantly! GLMapView.sync() gets left==right in glOrthof because MapSceneModel.getWidth\/getHeight return 0. Need to store real dimensions in the MapSceneModel
                  stub:<\/p>\n\n\n\n
                  \u25cf Check GLMapView.sync and MapSceneModel.create signature
                  $
                  ATAK_SRC=\/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main
                  echo “=== GLMapView.sync around line 1422 ===”
                  find “$ATAK_SRC” -name “GLMapView.java” | head -1 | xargs -I{} sed -n ‘1410,1440p’ {}\u2026
                  \u2514 117 lines\u2026<\/p>\n\n\n\n
                  \u25d0 Now I see what’s needed. The crash is:<\/p>\n\n\n\n
                    GLES20FixedPipeline.glOrthof(this.currentPass.left, this.currentPass.right, this.currentPass.bottom, this.currentPass.top, (float) this.currentPass.scene.camera.near, (float) \n  this.currentPass.scene.camera.far);<\/code><\/pre>\n\n\n\n
                  left == right<\/code> means the viewport bounds are both 0. This comes from currentPass.restore(this)<\/code> which reads the camera data from the scene. Since our MapSceneModel returns zeros
                  for everything, camera.near = camera.far = 0<\/code> also, and left = right = 0<\/code>.<\/p>\n\n\n\n
                  The root cause is that getWidth(1L)<\/code> and getHeight(1L)<\/code> return 0, so the scene dimensions are zero, which cascades into the ortho matrix calculation. I need to create a proper
                  MapSceneState<\/code> struct that holds the actual width, height, dpi, and focus coordinates, then initialize it properly in the create<\/code> method.<\/p>\n\n\n\n
                  But actually, tracing through the code flow\u2014currentPass.restore(this)<\/code> is calling JNI methods like get_left<\/code>, get_right<\/code>, get_bottom<\/code>, get_top<\/code> on the GLMapView pointer, and
                  these stubs are all returning 0. That’s why left == right<\/code>, which causes the crash in glOrthof<\/code>.<\/p>\n\n\n\n
                  The real problem is that our fake native GLMapView object (with value 1L) has no actual state, so all these viewport queries return 0. I’m weighing two approaches: either store real
                  screen dimensions in the MapSceneModel when it’s created, or populate the native GLMapView object with actual viewport data so the JNI stubs can return meaningful values.<\/p>\n\n\n\n
                  Option A seems cleaner since we already have width and height available at creation time. But the crash itself\u2014where left == right<\/code> in the orthographic projection\u2014suggests the
                  issue originates from currentPass<\/code> state, which gets restored from somewhere in the GLMapView. I need to trace through the PassState.restore() method to understand where these
                  viewport bounds actually come from.<\/p>\n\n\n\n
                  \u25cf Now I need to understand where currentPass.left\/right come from in sync():<\/p>\n\n\n\n
                  \u25cf Find PassState.restore to trace left\/right source
                  $
                  ATAK_SRC=\/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main
                  echo “=== GLMapView.PassState.restore ===”
                  find “$ATAK_SRC” -name “GLMapView.java” | head -1 | xargs grep -n “class PassState|void restore|left|right|bottom|top|_left|_right” | grep -v “\/\/” | head -40\u2026
                  \u2514 49 lines\u2026<\/p>\n\n\n\n
                  \u25d0 Now I see it! GLMapView<\/code> is created with left, bottom, right, top<\/code> parameters. Looking at how it’s created:<\/p>\n\n\n\n
                    public GLMapView(GLMapSurface surface, int left, int bottom, int right, int top) {\n      this(surface, surface.getMapView().getGlobe(), left, bottom, right, top);\n  }<\/code><\/pre>\n\n\n\n
                  And it’s created from GLMapSurface<\/code>. Let me check what left\/bottom\/right\/top values are passed.<\/p>\n\n\n\n
                  But more importantly – currentPass.left\/right\/bottom\/top<\/code> – how are these set? Are they set by the sync()<\/code> method from some JNI call? Or are they the constructor parameters?<\/p>\n\n\n\n
                  I’m tracing through the rendering pipeline where currentPass<\/code> gets used in the orthographic projection call, and I’m seeing JNI stubs that retrieve left\/right values but they’re
                  returning zero. I need to find where restore()<\/code> actually populates these viewport bounds.<\/p>\n\n\n\n
                  Looking at the constructor and the GLMapView.create<\/code> stub, I can see the issue: the native creation method receives the viewport parameters but our stub doesn’t store them, so when
                  sync()<\/code> later calls the getter stubs, they have nothing to return. I need to make the stub actually cache those left\/bottom\/right\/top values so they’re available when the sync
                  method reads them back. So the JNI signature takes left, bottom, right, top coordinates when creating GLMapView, and these same bounds are accessible through getter methods. The
                  crash happens because glOrthof<\/code> is being called with left==right (both zero), which comes from the camera’s near\/far values that our MapSceneModel is returning as zeros.<\/p>\n\n\n\n
                  The real issue is that currentPass.left\/right<\/code> are being populated from currentPass.restore(this)<\/code>, which reads from native state. I need to trace through the PassState class and
                  understand what its restore method actually does.<\/p>\n\n\n\n
                  \u25cf Trace currentPass.left\/right assignment
                  $
                  find \/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main -name “GLMapView.java” | head -1 | xargs -I{} grep -n
                  “get_left|get_right|get_bottom|get_top|PassState|class State|void restore|left =|right =|bottom =|top =” {} | grep -v “\/\/|deprecated|javadoc|*” | head -40<\/p>\n\n\n\n
                  \u2514 25 lines\u2026<\/p>\n\n\n\n
                  \u25cf Read PassState.restore and constructor initialization
                  $
                  ATAK_SRC=\/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main
                  echo “=== PassState.restore (line 2618) ===”
                  find “$ATAK_SRC” -name “GLMapView.java” | head -1 | xargs -I{} sed -n ‘2618,2680p’ {}\u2026
                  \u2514 166 lines\u2026<\/p>\n\n\n\n
                  \u25d0 Now I understand the full picture:<\/p>\n\n\n\n
                    \n
                  1. GLMapView(context, globe, left, bottom, right, top)<\/code> is called with left=0, bottom=0, right=surface.width-1, top=surface.height-1<\/code><\/li>\n\n\n\n
                  2. create(ctxptr, globeptr, left, bottom, right, top, legacy)<\/code> JNI stub returns SHARED pointer, stores nothing<\/li>\n\n\n\n
                  3. currentScene.scene = new MapSceneModel(dpi, width, height, proj, ...)<\/code> – this calls MapSceneModel_create<\/code> which our stub ignores the width\/height but stores 0<\/li>\n\n\n\n
                  4. A clone of the scene is created for the current pass, then sync()<\/code> retrieves various state flags and calls currentPass.restore(this)<\/code> to copy the viewport bounds into the main
                    view’s properties<\/li>\n\n\n\n
                  5. Finally, glOrthof()<\/code> is invoked with those bounds to set up the orthographic projection, but I’m trying to trace where currentPass.left\/right\/bottom\/top<\/code> actually get their
                    values from in the first place Looking at the PassState constructor, it copies viewport bounds directly from the GLMapView, but I need to figure out which constructor instantiates currentPass<\/code> and whether those
                    bounds come from native synchronization or are set earlier in the flow.<\/li>\n<\/ol>\n\n\n\n
                    \u25cf Read GLMapView.sync() from start to crash point
                    $
                    find \/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main -name “GLMapView.java” | head -1 | xargs -I{} sed -n ‘1380,1425p’ {}<\/p>\n\n\n\n
                    \u2514 46 lines\u2026<\/p>\n\n\n\n
                    \u25d0 Now I see the full picture:1. sync(this.pointer.raw, this, false)<\/code> and sync(this.pointer.raw, this, true)<\/code> are JNI calls that populate currentPass<\/code> and currentScene<\/code><\/p>\n\n\n\n
                      \n
                    1. sync(long pointer, GLMapView view, boolean passState)<\/code> is a JNI method that reads the native state and fills in the Java view fields<\/li>\n\n\n\n
                    2. Since our stub for sync<\/code> does nothing, currentPass.left = 0, currentPass.right = 0, currentPass.top = 0, currentPass.bottom = 0<\/code><\/li>\n\n\n\n
                    3. Then glOrthof(0, 0, 0, 0, 0, 0)<\/code> \u2192 left == right<\/code> crash!<\/li>\n\n\n\n
                    4. The real issue is that the sync<\/code> JNI method needs to properly initialize the viewport bounds, but implementing it fully would require native callbacks to Java. A simpler fix is
                      to just set currentPass<\/code> to the actual viewport dimensions\u2014something like left=0, bottom=0, right=width-1, top=height-1. a full-screen view. The cleanest approach is to implement the sync<\/code> JNI stub to call back to Java and set the pass boundaries based on the view dimensions. But that requires knowing the surface
                      dimensions from native code, which gets complicated with JNI callbacks. Looking at this differently: the _right<\/code> and _top<\/code> fields already get set correctly based on surface dimensions in the Java code, but the native sync is zeroing out _left<\/code> and
                      _bottom<\/code>. I need to figure out how to preserve or properly initialize those boundary values instead of relying on the native state. to implement the sync JNI method to populate the
                      currentPass with correct values. The key fields are:<\/li>\n<\/ol>\n\n\n\n
                        \n
                      • left<\/code>: left pixel bound (0)<\/li>\n\n\n\n
                      • right<\/code>: right pixel bound (surface.width – 1)<\/li>\n\n\n\n
                      • top<\/code>: top pixel bound (surface.height – 1)<\/li>\n\n\n\n
                      • bottom<\/code>: bottom pixel bound (0)<\/li>\n\n\n\n
                      • drawMapResolution<\/code>: the map resolution (OSMUtils.mapnikTileResolution(0))<\/li>\n\n\n\n
                      • scene<\/code>: the MapSceneModel (already set in Java)<\/li>\n\n\n\n
                      • camera.near\/far<\/code>: reasonable values for ortho projection The sync JNI method signature would be:
                        Java_com_atakmap_map_opengl_GLMapView_sync(JNIEnv*, jclass, jlong pointer, jobject glMapView, jboolean passState)<\/code> I need to implement this to get the surface dimensions from the GLMapView Java object via JNI reflection, then set the PassState fields (left, right, top, bottom) based on those
                        dimensions and apply a reasonable draw map resolution. Let me work through a simpler approach where I access the view’s surface to extract width and height, then populate the pass
                        state accordingly. I’m realizing the real issue is that glOrthof<\/code> crashes when left equals right, so instead of trying to implement the full JNI callback mechanism, I should focus
                        on making sure the sync method populates the view’s PassState with valid orthographic bounds that won’t cause a crash. The sync JNI method needs to set those fields on the Java
                        object directly rather than trying to call back into Java. Let me check what initial left\/bottom\/right\/top values GLMapSurface passes to the GLMapView constructor to understand what valid bounds should look like.<\/li>\n<\/ul>\n\n\n\n
                        \u25cf Find sync JNI signature and GLMapSurface viewport setup
                        $
                        ATAK_SRC=\/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main
                        echo “=== GLMapSurface constructor – how GLMapView is created ===”
                        find “$ATAK_SRC” -name “GLMapSurface.java” | head -1 | xargs -I{} sed -n ‘100,200p’ {}\u2026
                        \u2514 132 lines\u2026<\/p>\n\n\n\n
                        \u25d0 Now I see the key information:<\/p>\n\n\n\n
                          \n
                        1. GLMapSurface<\/code> creates GLMapView<\/code> with left=0, bottom=0, right=GLMapView.MATCH_SURFACE, top=GLMapView.MATCH_SURFACE<\/code><\/li>\n\n\n\n
                        2. MATCH_SURFACE<\/code> is a special constant that triggers: if (_right == MATCH_SURFACE) _right = _surface.getWidth() - 1; if (_top == MATCH_SURFACE) _top = _surface.getHeight() - 1;<\/code> So _left = 0, _bottom = 0, _right = surface.width - 1, _top = surface.height - 1<\/code><\/li>\n\n\n\n
                        3. The sync<\/code> JNI method receives a pointer and callback to populate the rendering pass state, but since my stub implementation does nothing, currentPass.left<\/code> and
                          currentPass.right<\/code> both stay at 0, which causes glOrthof(0, 0, ...)<\/code> to crash. I need to actually implement the sync<\/code> method to set these values properly. The straightforward fix would be to access the Java glMapView<\/code> object’s viewport fields and populate currentPass<\/code> with the correct left\/right\/top\/bottom bounds, plus set
                          drawMapResolution<\/code> and the camera’s near\/far planes to non-zero values. However, that requires JNI callbacks which adds complexity. Let me reconsider\u2014since sync<\/code> already receives
                          the Java GLMapView<\/code> object, I should be able to directly access its viewport fields that were set during construction and use those to initialize currentPass<\/code>. Looking at the constructor flow more carefully: GLMapSurface<\/code> creates the view with MATCH_SURFACE<\/code> dimensions, the constructor sets initial bounds, then calls sync()<\/code> which
                          eventually restores values from currentPass<\/code>\u2014but currentPass<\/code> starts with zeros, causing the orthographic projection to fail. The issue is that currentPass<\/code> needs to be populated
                          with actual viewport dimensions before restore()<\/code> is called. So I need to populate those currentPass<\/code> fields from the Java GLMapView’s _left<\/code>, _right<\/code>, _top<\/code>, _bottom<\/code> values
                          in the sync JNI method. But I should check when MATCH_SURFACE<\/code> gets resolved to an actual dimension\u2014it looks like that happens when the property is accessed, converting it to the
                          surface width or height minus one. The problem is that during the GLMapView constructor when sync()<\/code> gets called, the GLSurfaceView might not have been measured yet, so getWidth()<\/code> could return 0, which would make
                          MATCH_SURFACE<\/code> resolve to -1 and break the bounds check. I need to figure out when the surface dimensions are actually available at construction time. So MATCH_SURFACE<\/code> is a
                          sentinel value that gets resolved lazily\u2014when getRight()<\/code> is called, if _right<\/code> still equals MATCH_SURFACE<\/code>, it calculates the actual width minus one and stores that. The native
                          side receives the raw constructor arguments including this sentinel value, which then gets resolved on demand rather than upfront. The issue is that our stub’s sync<\/code> method doesn’t do anything, leaving currentPass<\/code> with zeros instead of the resolved dimensions. I need to implement the JNI sync<\/code> call to
                          actually invoke getRight()<\/code> and getTop()<\/code> on the Java object so the native side gets the real values. Writing JNI sync implementation\u2026 I’m realizing this approach is getting too complicated with all the JNI field access. Let me step back and try something simpler\u2014what if I just
                          patch the Java code directly to add a guard check before calling glOrthof<\/code>, making sure the viewport dimensions are actually valid before passing them to the graphics call? Still
                          writing JNI code\u2026 Setting the remaining boundary fields and map resolution, then accessing the scene object to configure camera parameters\u2026 I’m realizing the PassState field is
                          likely “currentPass” with the type descriptor Lcom\/atakmap\/map\/opengl\/GLMapView$PassState;<\/code> for the inner class. Looking at the source code, the left\/right\/top\/bottom fields are
                          integers based on how they’re initialized, so I need to use the int field type descriptors when accessing them through JNI. The crash shows glOrthof<\/code> is being called with left == right == 0<\/code>, which violates the requirement that these values be different. If I can set right<\/code> to something like the
                          surface width minus one (around 2231), that would fix the immediate crash. But there’s also a secondary issue: near == far == 0.0<\/code> would also crash since glOrthof<\/code> requires these
                          to be different values. The priority is fixing the left\/right equality first, but I’ll need to address the near\/far issue as well. Looking at the Android Matrix.orthoM validation\u2026 Checking MapSceneModel.init() to see where camera.near and camera.far get their values\u2026 Implementing JNI stubs\u2026 Writing the JNI implementations\u2026<\/li>\n<\/ol>\n\n\n\n
                          \u25cf Crash advanced significantly to glOrthof. Three fixes needed: implement sync JNI to set currentPass.left\/right\/top\/bottom from surface dims, and getCameraNear\/getCameraFar to return
                          non-zero values (they all return 0, failing the ortho matrix validity checks):<\/p>\n\n\n\n
                          \u25cf Check PassState fields and camera JNI sigs
                          $
                          # Verify the field names in PassState class
                          ATAK_SRC=\/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main
                          echo “=== PassState field declarations ===”
                          find “$ATAK_SRC” -name “GLMapView.java” | head -1 | xargs -I{} sed -n ‘2500,2570p’ {}\u2026
                          \u2514 139 lines\u2026<\/p>\n\n\n\n
                          \u25d0 Now I have all the info I need. The PassState class is actually GLMapView.State<\/code> (a static inner class named State<\/code>). Let me check the actual field:<\/p>\n\n\n\n
                          Looking at the sync crash area:<\/p>\n\n\n\n
                            GLES20FixedPipeline.glOrthof(this.currentPass.left, this.currentPass.right, this.currentPass.bottom, this.currentPass.top, (float) this.currentPass.scene.camera.near, (float) \n  this.currentPass.scene.camera.far);<\/code><\/pre>\n\n\n\n
                          And the fields are: currentPass.left\/right\/top\/bottom<\/code> (from GLMapView.State<\/code> inner class), and currentPass.scene.camera.near\/far<\/code>.<\/p>\n\n\n\n
                          The JNI type descriptor is Lcom\/atakmap\/map\/opengl\/GLMapView$State;<\/code>. Looking at the copy method, _right<\/code> gets assigned from view._right<\/code>, and during MATCH_SURFACE resolution it
                          gets set to _surface.getWidth() - 1<\/code>. But since sync doesn’t run in this case, currentPass.right<\/code> remains unresolved at MATCH_SURFACE<\/code>.<\/p>\n\n\n\n
                          Now I’m tracing through the MapCamera initialization in MapSceneModel.init()<\/code> where the near and far planes are being set to 0.0 from JNI calls. The issue is determining whether
                          this.camera<\/code> is a com.atakmap.map.MapCamera<\/code> or gov.tak.api.engine.map.MapCamera<\/code> \u2014 the crash is pointing to the latter, which comes from currentPass.scene<\/code> being a
                          gov.tak.api.engine.map.MapSceneModel<\/code> from GLMapView.State<\/code>. I’m seeing that the TAK Platform’s MapSceneModel<\/code> wraps the internal com.atakmap.map.MapSceneModel<\/code>, and during
                          initialization it copies the camera’s near and far values from the underlying implementation\u2014but those JNI calls are returning 0.0, which is causing the crash when trying to use
                          these values.<\/p>\n\n\n\n
                          The fix is straightforward: the JNI stubs for getCameraNear<\/code> and getCameraFar<\/code> should return -1.0 and 1.0 respectively, which are standard orthographic projection bounds. However,
                          that only addresses the near\/far problem\u2014I still need to fix the left\/right\/top\/bottom viewport values through the sync JNI call.<\/p>\n\n\n\n
                          Looking at the code, currentPass<\/code> is a field of GLMapView<\/code> with type GLMapView.State<\/code>, which is a public static class with public fields, so JNI can access them directly. The
                          sync method needs to populate currentPass.left\/right\/top\/bottom<\/code> from the viewport dimensions before the orthographic projection is applied.<\/p>\n\n\n\n
                          \u25cf Find currentPass field type declaration
                          $
                          find \/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main -name “GLMapView.java” | head -1 | xargs grep -n “currentPass|currentScene|PassState|State current” |
                          grep -E “PassState|State curr|currentPass.=|currentScene.<\/em>=” | head -20<\/p>\n\n\n\n
                          \u2514 9 lines\u2026<\/p>\n\n\n\n
                          \u25d0 currentPass<\/code> is of type State<\/code> (which is GLMapView.State<\/code>). JNI type: Lcom\/atakmap\/map\/opengl\/GLMapView$State;<\/code>.<\/p>\n\n\n\n
                          Fields left<\/code>, right<\/code>, top<\/code>, bottom<\/code> are int<\/code> in State<\/code>.scene<\/code> is of type MapSceneModel<\/code> (which package? Looking at line 554 where currentScene.scene<\/code> is set to a
                          MapSceneModel<\/code> – since GLMapView uses new MapSceneModel(...)<\/code> which from the import is com.atakmap.map.MapSceneModel<\/code>.<\/p>\n\n\n\n
                          So scene<\/code> is of type com.atakmap.map.MapSceneModel<\/code>. Now I need to trace what camera<\/code> is on that MapSceneModel<\/code> class to understand the crash at line 1422 where
                          this.currentPass.scene.camera.near<\/code> is accessed. So MapSceneModel<\/code> has a camera<\/code> field that’s initialized as a MapCamera<\/code> object, and the JNI code populates its properties like
                          near<\/code> and far<\/code> from the native implementation. That means the crash is happening when trying to access the near<\/code> property on this MapCamera<\/code> instance through the scene object.
                          currentPass.scene.camera.far<\/code> is also 0.0. But I’m realizing there’s a type mismatch here\u2014currentPass.scene<\/code> is being assigned from currentScene.scene<\/code>, and I need to verify
                          whether State.scene<\/code> is actually com.atakmap.map.MapSceneModel<\/code> or the API version gov.tak.api.engine.map.MapSceneModel<\/code>, since that affects which camera<\/code> field is being used.<\/p>\n\n\n\n
                          \u25cf Check GLMapView imports
                          $
                          find \/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main -name “GLMapView.java” | head -1 | xargs -I{} sed -n ‘1,30p’ {}<\/p>\n\n\n\n
                          \u2514 30 lines\u2026<\/p>\n\n\n\n
                          \u25cf Check GLMapView imports continued
                          $
                          find \/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main -name “GLMapView.java” | head -1 | xargs -I{} sed -n ‘30,60p’ {}<\/p>\n\n\n\n
                          \u2514 32 lines\u2026<\/p>\n\n\n\n
                          \u25cf Check GLMapView imports for MapSceneModel
                          $
                          find \/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main -name “GLMapView.java” | head -1 | xargs -I{} sed -n ‘60,90p’ {}<\/p>\n\n\n\n
                          \u2514 32 lines\u2026<\/p>\n\n\n\n
                          \u25d0 It’s com.atakmap.map.MapSceneModel<\/code>. So currentPass.scene<\/code> is of type com.atakmap.map.MapSceneModel<\/code>.<\/p>\n\n\n\n
                          Now, com.atakmap.map.MapSceneModel<\/code> has a camera<\/code> field. Looking at the init()<\/code> code I saw earlier, this.camera.near = _impl.camera.near<\/code> where _impl<\/code> is also a
                          com.atakmap.map.MapSceneModel<\/code>.Actually wait, I’m confused about two MapSceneModel classes. There’s:1. com.atakmap.map.MapSceneModel<\/code> (in takkernel, the main one used in
                          GLMapView)<\/p>\n\n\n\n
                            \n
                          1. gov.tak.api.engine.map.MapSceneModel<\/code> (higher-level API) But looking at GLMapView<\/code>, it imports com.atakmap.map.MapSceneModel<\/code>. And State.scene<\/code> is of type MapSceneModel<\/code>, which resolves to com.atakmap.map.MapSceneModel<\/code>. com.atakmap.map.MapSceneModel<\/code> has a camera<\/code> field\u2026 Let me find the camera<\/code> field and its type. From the init()<\/code> code in com.atakmap.map.MapSceneModel<\/code>, it looks like the
                            camera is lazily initialized if it’s null. Now I need to look at the takkernel version specifically to understand how it initializes its display model, dimensions, and projection settings during the init process. I’m seeing
                            the JNI method signatures for camera properties like getCameraNear<\/code> and getCameraFar<\/code> in the MapSceneModel<\/code> class. Looking at the init()<\/code> method, I can see the wrapper
                            MapSceneModel<\/code> is copying camera properties from _impl.camera<\/code> \u2014 so _impl<\/code> must be the inner implementation class that actually holds the camera reference. I need to trace
                            through the MapSceneModel camera initialization to understand what type the camera field is and whether the JNI calls for near\/far clipping planes are actually being applied. Let me
                            look at the broader initialization code to see how the camera gets set up and what default values it starts with.<\/li>\n<\/ol>\n\n\n\n
                            \u25cf Read MapSceneModel.init() camera section
                            $
                            find \/home\/spectrcyde\/NerfEngine\/assets\/AndroidTacticalAssaultKit-CIV-main\/takkernel -name “MapSceneModel.java” -path “\/atakmap\/map\/<\/em>” | head -1 | xargs -I{} sed -n ‘125,220p’ {}<\/p>\n\n\n\n
                            \u2514 97 lines\u2026<\/p>\n\n\n\n
                            \u25d0 Now I see the full picture. The camera.near<\/code> and camera.far<\/code> in com.atakmap.map.MapSceneModel<\/code> come from:<\/p>\n\n\n\n