Basically the whole screen as a map;

In terms of the original question, is object creation and texture loading thread-safe?

I am creating objects and loading textures in a separate thread and then passing the objects to a Handler in the renderer which adds them to the world from a Stack in onDrawFrame(). Randomly these objects are not being displayed (incidentally all the objects are map tiles - 2 triangles with one texture).

Logcat reports that 9 textures are loaded, 9 objects are added to the world/ compiled, but potentially only 4 will actually be displayed.

Should texture's be loaded and/ or objects created in the render thread as well as adding?

The QCAR/ Vuforia is not OpenSource, but it is free to use in private and commercial apps; https://developer.vuforia.com/legal/license/2-8

Which bit can't you use (commercial reasons or technical?)


frameBuffer.clear(background);

/* Call our native QCAR function to render the video
 * background and scan images for recognition */
renderFrame();

// Render the AR data to the jPCT scene
theWorld.renderScene(frameBuffer);
theWorld.draw(frameBuffer);

// Display our content...
frameBuffer.display();


Unfortunately I can't answer your question directly (as to why), but I struggled for sometime getting a stable implementation whereby the AR data was always on top of the camera, especially whilst toggling the camera preview on and off.
I always implemented this in code, not using a layout as follows;

In the main activity onCreate method, in this order;

Create the CameraPreview.
Create the SurfaceView (with renderer)

In the CameraPreview constructor;
    RelativeLayout tmpLayout = new RelativeLayout( appContext );
    tmpLayout.addView(this, 0,
    new LayoutParams(
    LayoutParams.FILL_PARENT,
    LayoutParams.FILL_PARENT)
    );
    activity.setContentView(tmpLayout);

In the SurfaceView constructor;
        setEGLContextClientVersion(2);

setEGLConfigChooser(new AAConfigChooser(this, true));

getHolder().setFormat(PixelFormat.TRANSLUCENT);

// Setup the renderer
mRenderer = new JpctRenderer( mainARView.orientationListener.tabletMode );
Activity activity = (Activity)mainARView.appContext;

// Add this view to the main activity
        setZOrderMediaOverlay(true);
    activity.addContentView(this, new LayoutParams(
    LayoutParams.FILL_PARENT,
    LayoutParams.FILL_PARENT));

If you want a UI on-top of both, do this in the main activity after creating the SurfaceView;
uiScreen = new UserInterfaceView(this);
addContentView(uiScreen, fillLayout);

In onResume;
camScreen.start();
augScreen.setVisibility(View.VISIBLE);
augScreen.onResume();

In onPause;
augScreen.setVisibility(View.INVISIBLE);
augScreen.onPause();
camScreen.stop();

Hope this helps.

M

Okay. So when you say render thread, should this be the onDrawFrame method; i.e. it reads from a synchronized list that has been populated by a Message() to completely detach from the rest of the app? (Object creation in another thread)

Cheers.

You could always use the Android camera parameters to get FOV values and then apply these to the WorldCamera...

In your camera class
        Camera.Parameters cameraParams = mCamera.getParameters();
        float hva = cameraParams.getHorizontalViewAngle();
        float vva = cameraParams.getVerticalViewAngle();

and then in the render class
Camera worldCamera = theWorld.getCamera();
float wid = worldCamera.convertDEGAngleIntoFOV( hvAngle );
float hig = worldCamera.convertDEGAngleIntoFOV( vvAngle );
worldCamera.setFOV( wid );
worldCamera.setYFOV( hig );

I use this method and it works fine except when rotating the device to portrait - The values should really be re-calculate when the camera activity is rotated (like in Wikitude), but I haven't implemented that as yet 

To answer one of your questions, the axis description is at http://www.jpct.net/wiki/index.php/Coordinate_system

interDist = plane.calcMinDistance( obj.getTransformedCenter(), upAxis );

if (interDist==Object3D.COLLISION_NONE) {
// translate -20 and re-test
}

if(!obj.isPlane) {
bbox = getWorldSpaceBounds(obj);
objHeight = bbox[3]-bbox[2];
}
// Do the clamping...
if (interDist!=Object3D.COLLISION_NONE) {
if(!obj.isPlane) {
Log.i(LOG_TAG, "Obj: "+obj.getParentFeatureID()+" Dist: "+interDist+" Height: "+objHeight/2);
}
trans.set( upAxis );
trans.scalarMul( interDist-obj.heightOffset-(objHeight/2) );
obj.translate( trans );
}

appears to sort all the models except one; this one reports an incorrect bounding box (a height of 16.8m instead of 10m), therefore the adjustment back to ground level is out.