ConeGeometry
entity as an example.ape::IConeGeometry
interface, we have to register a static native Java-function in the ApertusJNI.java file. So take a glance at the IConeGeometry
interface:ConeGeometry
case, it looks like this:set
, get
, is
etc., comes the entity name, then the "subject" (e.g. ParentNode
). Comparing the two set of function headers, note that the rules are:std::string
turns into String
ape::Entity
types turn into String
, as we access them by their IDsape::Vector2
, ape::Color
, etc. turns into separate float
values, as we pursue to use primitive types whenever it is possible.enum
types turn into int
variablesape::CoreConfig
) there is a corresponding apeJNI<entityName>.cpp file (e.g. apeJNICoreConfig.cpp).ConeGeometry
entity, we create an apeJNIConeGeometry.cpp file, where we place the JNI-functions. The rule is that for a static native function in the packaganame
package, and className
class with functionName
name, we have its corresponding JNI-function header as:ape::ISceneManager
, to query and modify our entities? We use the ape::JNIPlugin
as a crutch.ape::JNIPlugin::getPluginPtr()
static function. So we query this pointer, and store it to a variable. Then we convert the entity id into a C-style string with the env
pointer:setParameters(...)
function our task is to set the parameters for the cone with the id name
. This goes naturally, just like we use the ApertusVR C++ API:ReleaseStringUTFChars(...)
function for every GetStringUTFChars(...)
allocation before leaving the function, otherwise it will cause memory leak, just like when somebody forgot to call delete
after new
.getParameters(...)
. The first half of the procedure goes exactly the same as in the case when we are not interested in any returning value. However, when we are, then we should ask for it on the same place where we set the parameters in the previous example:ape::GeometryConeParameters
) are returned as arrays. So in our case this complex type in C++ looks like the following struct
:jfloatArray
with the help of the env
pointer, and then place this buffer into the newly create jfloatArray
, and then just return it:SOURCE
list:org.apertusvr
package. So navigate to the corresponding folder, and create the new file for the wrapper class, as apeConeGeometry.java!ape::IConeGeometry
is a subclass of the ape::Geometry
interface. We have to follow this structure here too. We assume that somebody already created the apeGeometry
wrapper for us, so we just type:apeEntity
superclass. In our case, we now that we are working with a ConeGeometry
, so we make a constructor with only one String parameter, and call the superclass's constructor with this String and the apeEntity.Type.GOMETRY_CONE
value:float x
and float y
, but an apeVector2
(which is part of the Java API).apeConeGeometry
, we should always provide a Builder class, which is an implementation of the apeBuilder
interface. This is really important if we want to cast from an apeEntity
or other superclass, because we have to instantiate one for it.