android: expose RenderableManager.PrimitiveType value

[rootkiller6788]

Summary

Expose the native value of RenderableManager.PrimitiveType by making its getValue() method public.

Motivation

External Android integrations need to pass the primitive topology through JNI (e.g. to RenderableManager.setGeometryAt() / Builder.geometry()). Today PrimitiveType.getValue() is package-private, so callers outside com.google.android.filament cannot obtain the underlying int.

The enum's values are not ordinals — they mirror the native backend::PrimitiveType which is "made to match GL" (LINE_STRIP = 3, skipping 2). So ordinal() cannot be used as a substitute.

Change

public int getValue() { return mType; }

This only changes Java API visibility and does not affect rendering behavior. Matches the request in #10263.

[pixelflinger]

sounds good, but don't mention OpenGL here, it shouldn't be relevant or required.

[romainguy]

I don't think that's the way to go, the Java bindings don't expose these values in the other enums. If there are APIs that don't take the enum, they should. The original issue mentions gltfio and it sounds like gltfio should just add extra APIs instead of doing this.

[rootkiller6788]

Review replies

pixelflinger: Thank you for the review! I've fixed the Javadoc as suggested — the OpenGL reference is gone, and getValue() now simply documents that it returns the value of the primitive type.

romainguy: Thanks for the feedback. I understand the concern about consistency — the other Java enums don't expose their values, and that's largely because they all map to their native counterparts via ordinal(). PrimitiveType is the one exception in the bindings: the native backend::PrimitiveType is explicitly "made to match GL" (filament/backend/include/backend/DriverEnums.h), so LINE_STRIP = 3 and the sequence skips 2. ordinal() would silently produce the wrong value (LINE_STRIP=2), which is why the enum already stores an explicit value and the bindings already pass it through getValue() internally (e.g. in Builder.geometry() and setGeometryAt()).

On "if there are APIs that don't take the enum, they should": the Java API surface already takes the enum directly — Builder.geometry() and RenderableManager.setGeometryAt() both accept PrimitiveType. This change doesn't add any new int-typed entry point; it only widens the visibility of the existing accessor so that external integrations (issue #10263) can bridge the value through their own JNI layer, where the enum instance isn't available on the native side.

Regarding gltfio adding extra APIs: gltfio is a C++ library and already works with the native enum directly; a Java-level API there would be a larger, separate change and wouldn't cover integrations that don't use gltfio. If you'd prefer that direction anyway I'm happy to explore it, but the visibility change here is minimal and behavior-preserving. Could you please take another look?

[romainguy]

Then instead of exposing just a single getValue() maybe all Java enums should have a toFilamentNative() or equivalent to at least be consistent (which for most enums would just be a call to ordinal()).

[rootkiller6788]

@romainguy You're right — a one-off getValue() is inconsistent with the rest of the bindings, so I've implemented the toFilamentNative() direction in commit 00c0c36:

• RenderableManager.PrimitiveType.getValue() is renamed to toFilamentNative(), still returning the primitive type's explicit native value (0/1/3/4/5, matching backend::PrimitiveType); all internal callers were updated.
• Every other hand-written Java enum that is passed to native code now exposes the same public int toFilamentNative() accessor. For most of them this is simply return ordinal();. The three enums whose native value cannot be derived from ordinal() are handled explicitly:
  • MaterialInstance.StencilFace → returns its bit-field mapping {0x1, 0x2, 0x3};
  • View.TargetBufferFlags → returns the flag's bit value;
  • RenderableManager.PrimitiveType → returns its explicit value.

A few enums are intentionally left without the accessor:

• the beamsplitter-generated part of View.java (generated code shouldn't be hand-edited);
• enums that are purely Java descriptors with no native counterpart (Colors.*, Material.Parameter.Type/Precision, NioUtils.BufferType);
• Fence.FenceStatus, which is a result type converted from native rather than an input, and whose ordinals don't match the native values (-1/0/1).

I compiled the full bindings with JDK 8 and verified the values returned by the special-cased enums against backend/DriverEnums.h. Could you take another look?

[romainguy]

Thanks, that looks good!

@pixelflinger can you check if you're ok with the name of the API?

[rootkiller6788]

Thanks @romainguy! Rebased onto the latest main so it's up to date.

@pixelflinger — happy to change toFilamentNative() if you'd prefer a different name, just let me know what you'd like.

[pixelflinger]

I think some of these enum on the java side are auto-generated by beamsplitter. The toFilamentNative() additions would be overwritten.

note: beamsplitter is currently broken. I will look at it asap.