No, that doesn't look like a problem in the model's setup...at least not as the sole reason of the problem. But it's actually impossible to tell what's going on there. Maybe some other GL setup going wrong, but it will be quite hard to find out. I would add a log output to every GL call in the Java version and then compare the trace that this produces with the same thing taken from the C# version while rendering the exact same scene. And then see, if there is a difference between the calls that these versions do. It will be quite a lot of work, I suppose, but you need some kind of reference to track this down and currently, you have none.

These polyline artifacts are indeed strange, but I don't think that you can do anything about them unless they are caused by different width settings in your code. In general, drawing lines using GL on Android isn't very reliable in my experience. I had devices that ignored the width altogether and just rendered single pixel lines no matter what.

How is your "additional object"-approach implemented? By adding a bunch of objects to form a path? In that case, you might want to use one (or a few) large object(s) instead and change the vertices on the fly. That will still impact performance, because the mesh will be constantly changing, but it might be fast enough. I did something similar as a proof of concept a while back for desktop jPCT, but it should work on Android as well, with some minor changes. The idea was to create an object with several, let's say 1000, polygons that are all out of sight at the start.

Then, as the object causing the trail moves, you move polygon by polygon back into view to form the trail. Once you hit the maximum number of polygons in the trail-object, you start moving polygons from the end of the trail to the start. Here's an example with a trail consisting of 1000 polygons: https://www.youtube.com/watch?v=E4I16yxCQDA

Here's the code for this demo:

import java.awt.Color;

import com.threed.jpct.*;
import com.threed.jpct.util.Light;

public class TrailTest {
private static int TRAIL_POLYGONS = 1000;

private World world;
private FrameBuffer buffer;
private Object3D sphere;

private Object3D trail;

public static void main(String[] args) throws Exception {
new TrailTest().loop();
}

public TrailTest() throws Exception {
world = new World();
world.setAmbientLight(100, 100, 100);

sphere = Primitives.getSphere(20, 1f);
sphere.build();
sphere.compile();
sphere.translate(-100, 0, 50);
world.addObject(sphere);

Camera cam = world.getCamera();
cam.setPosition(0, -50, 0);
cam.lookAt(sphere.getTransformedCenter());

Light light = new Light(world);
light.setPosition(new SimpleVector(-100, 0, -150));
light.setAttenuation(-1);

trail = createTrailObject(sphere);
world.addObject(trail);
}

/**
* This looks a bit hacky...it creates an object with a defined number of
* unique polygons that are all out of sight. The vertex controller will
* then take polygons from this soup and arrange them to form the trail.
*
* @param emitter
* @return
*/
private Object3D createTrailObject(Object3D emitter) {
Logger.log("Creating trail object...");
Object3D trail = new Object3D(TRAIL_POLYGONS);
trail.disableVertexSharing();
for (int i = 0; i < TRAIL_POLYGONS / 2; i++) {
trail.addTriangle(new SimpleVector(-1100000 + i, -1200000 + i, -1300000 + i), new SimpleVector(-1400000 + i, -1500000 + i, -1600000 + i), new SimpleVector(
-1700000 + i, -1800000 + i, -1900000 + i));
trail.addTriangle(new SimpleVector(2000000 + i, 2100000 + i, 2200000 + i), new SimpleVector(2300000 + i, 2400000 + i, 2500000 + i), new SimpleVector(2600000 + i,
2700000 + i, 2800000 + i));
}

trail.calcNormals();
trail.getMesh().setVertexController(new TrailBlazer(emitter), false);
trail.forceGeometryIndices(false);
trail.compile(true);
trail.build();

trail.setAdditionalColor(Color.YELLOW);
trail.setCulling(Object3D.CULLING_DISABLED);
trail.setTransparency(0);

return trail;
}

private void loop() throws Exception {
buffer = new FrameBuffer(640, 480, FrameBuffer.SAMPLINGMODE_NORMAL);
buffer.disableRenderer(IRenderer.RENDERER_SOFTWARE);
buffer.enableRenderer(IRenderer.RENDERER_OPENGL);

float cnt = 0;
float y = 0;
float yAdd = -0.1f;

while (!org.lwjgl.opengl.Display.isCloseRequested()) {
SimpleVector lastTrans = sphere.getTranslation();
sphere.translate((float) Math.sin(cnt), yAdd, (float) Math.cos(cnt));
SimpleVector newTrans = sphere.getTranslation();
lastTrans.sub(newTrans);
sphere.getRotationMatrix().setTo(lastTrans.getRotationMatrix());

trail.getMesh().applyVertexController();
trail.touch();

cnt += 0.05f;

if (y < -30) {
yAdd = 0.1f;
} else if (y > 30) {
yAdd = -0.1f;
}
y += yAdd;

buffer.clear(java.awt.Color.BLACK);
world.renderScene(buffer);
world.draw(buffer);
buffer.update();
buffer.displayGLOnly();
Thread.sleep(10);
}
System.exit(0);
}

private static class TrailBlazer extends GenericVertexController {
private int maxPos = TRAIL_POLYGONS / 2;
private int pos = 0;
private Object3D emitter = null;
private SimpleVector p0 = new SimpleVector();
private SimpleVector p1 = new SimpleVector();
private SimpleVector p2 = new SimpleVector();
private SimpleVector p3 = new SimpleVector();
private SimpleVector center = new SimpleVector();
private SimpleVector lastP2 = null;
private SimpleVector lastP3 = null;
private SimpleVector z = new SimpleVector();
private SimpleVector x = new SimpleVector();
private SimpleVector tmp = new SimpleVector();

private static final long serialVersionUID = 1L;

public TrailBlazer(Object3D emitter) {
this.emitter = emitter;
}

public void apply() {
center = emitter.getTransformedCenter(center);
SimpleVector[] dest = this.getDestinationMesh();

z = emitter.getRotationMatrix().getZAxis(z);
x = emitter.getRotationMatrix().getXAxis(z);

if (lastP2 == null) {
tmp.set(center);
tmp.sub(x);
lastP2 = new SimpleVector(tmp);
tmp.add(x);
tmp.add(x);
lastP3 = new SimpleVector(tmp);
}

p0.set(lastP2);
p1.set(lastP3);

int cPos = pos * 6;

tmp.set(center);
tmp.sub(z);
tmp.sub(x);
p2.set(tmp);
tmp.add(x);
tmp.add(x);
p3.set(tmp);

dest[cPos++].set(p0);
dest[cPos++].set(p1);
dest[cPos++].set(p3);

dest[cPos++].set(p2);
dest[cPos++].set(p0);
dest[cPos].set(p3);

pos++;
if (pos >= maxPos) {
pos = 0;
}
lastP2.set(p2);
lastP3.set(p3);
}
}
}



It's curPos. The normal rendering mode (i.e. not for compiled objects) fill a given vertex array from 0 to <some vertex count> and renders that in one batch. How much it fills, depends on the object. If the object is uniformly textured (i.e. it uses the same texture(s) for each polygon), this value should be somewhere near the maximum size of that vertex array.

Have you tried what happens if you disable vertex arrays in the config? If that still renders junk, your problem isn't in the rendering but somewhere before.

9 vertices isn't right for a sphere. In uncompiled rendering mode, the number of vertices in one batch is dynamic but 9 for a uniformly textured sphere seems off.

I've released 1.32 yesterday. It has been available for quite some time as a beta release linked to from several threads. The version number is the same between desktop and android.

Get it from here (links should be fixed!): https://www.jpct.net/download.html

Changes of the desktop version:

• Fixed a bug with cloning certain objects.
• Added the option to leave the inputstream open when loading a texture.
• Added support for transparency to (de-)serialized objects.
• Added the option to set the TextureManager into "forgiving" mode.
• Converted int parameters in blit()-methods to float.
• Added a compileAllObjects() method to World.
• Improved batch size for compiled objects.
• Added option to set specific lights for an Object3D.

Changes of the Android version:

• Fixed a bug with cloning certain objects.
• Fixed a bug which caused wrong clipping when setting a bounding box for a one-polygon object.
• Added the option to leave the inputstream open when loading a texture.
• Added support for transparency to (de-)serialized objects.
• Fixed a rare problem with blitting buffers.
• Added the option to set the TextureManager into "forgiving" mode.
• Fixed point sizes in ES 2.0 modes.
• Converted int parameters int blit()-methods to float.
• Improved batch size for compiled objects.
• Added option to set specific lights for an Object3D.
• Fixed the clearAll-option for render targets.

Polyline has a setWidth() method. Can't you just change the width according to the distance? Or maybe I don't fully understand the problem...

Glvertexpointer just defines the format of the vertices in the array, not the array itself. This has to be done somehow, I don't see why it should be an issue here.