Ok, I've updated https://jpct.de/download/beta/jpct_ae.jar. If that still doesn't have the same effect as display(), then I can do one more thing to it. Please let me know how it works out.

FrameBuffer#flushBlittingPipeline() seems to work now without any additional FrameBuffer#display() calls (except for the final call at the end of the draw call).

Hello,

I believe I've found a minor blitshader bug, it's mostly about the blits that follow (whether these use another blitshader or no blitshader) after you are done using the blitshader in a single draw call.
I do follow the instructions I've read elsewhere on this forums:

It should work. At least I see no reason, why it shouldn't. Just make sure not to do this:

Code: [Select]

fb.setBlittingShader(...);
fb.blit(...);
fb.setBlittingShader(null);

That doesn't work, because blits are buffered but the shader isn't. If you need to reset the shader in the process, make sure to execute the blits before. You can force this by blitting a dummy blit from some other texture. Like:

Code: [Select]

fb.setBlittingShader(...);
fb.blit(...);
fb.blit(...); // <- Dummy-blit (1x1 transparent pixel with some other texture or something)
fb.setBlittingShader(null);


Now in my case, I use:
fb.setBlittingShader(shader1);
fb.blit(...);
fb.blit(...); // <- Dummy-blit (1x1 transparent pixel with some other texture or something)
fb.setBlittingShader(null);
fb.setBlittingShader(shader1);
fb.blit(...);
fb.blit(...); // <- Dummy-blit (1x1 transparent pixel with some other texture or something)
fb.setBlittingShader(null);
fb.setBlittingShader(shader2);
fb.blit(...);
fb.blit(...); // <- Dummy-blit (1x1 transparent pixel with some other texture or something)
fb.setBlittingShader(null);
Every blit using the first shader seems to go fine but once another shader or no shader is used, blitting is kinda broken (not on all devices but most).
- When you blit (after having used the first shader) with no shader, something that doesn't match the original texture you're trying to blit is shown.
- When you blit (after having used the first shader) with another shader, either nothing is shown or the correct result is shown. (50/50 depending on device)
- When you blit (after having used the first shader) with no/another shader AND you used fb.display() before these blits, then the correct result will be shown in all cases.

So it seems that now fb.display() is required if
- you want to keep blitting normally after the first blits with shader
- you want to use another blitshader to blit with
Though, I'm not sure if fb.display() is intended to be used like that

Cheers,
Abiram

Hello,

I have been digging around a little for the memory issues I have concerning texture uploading since I do use pretty huge textures.
It seems that jPCT-AE requires twice the size of a texture (in peak memory usage) in JVM RAM: the original pixeldata of the texture + the buffer used for uploading.
But I believe that on modern day devices you can actually use tricks to consume near nothing in the JVM RAM when loading such huge textures.
I believe jPCT-AE doesn't support these features out of the box because it's been directly ported from the PC version and to provide backwards compatibility with the very old devices.

Here's the class I use to upload textures now (feel free to use it or make your own modifications to it):
package com.aeroshark333.artofearthify.utils;

import android.graphics.Bitmap;
import android.opengl.GLES20;
import android.opengl.GLUtils;

import com.threed.jpct.RGBColor;
import com.threed.jpct.Texture;

// Created by Abiram/AeroShark333
public class CustomTexture extends Texture {
    final Bitmap bmp;

    public CustomTexture(Bitmap image) {
        super(2, 2, RGBColor.BLACK);
        this.bmp = image;
    }

    public int loadTexture(final boolean forceNearest, final boolean keepInMemory){
        final int[] textureHandle = new int[1];

        GLES20.glGenTextures(1, textureHandle, 0);

        if (textureHandle[0] != 0)
        {
            // Bind to the texture in OpenGL
            GLES20.glBindTexture(GLES20.GL_TEXTURE_2D, textureHandle[0]);

            // Set filtering
            if (!forceNearest) {
                GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MIN_FILTER, GLES20.GL_LINEAR);
                GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MAG_FILTER, GLES20.GL_LINEAR);
            }else {
                GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MIN_FILTER, GLES20.GL_NEAREST);
                GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MAG_FILTER, GLES20.GL_NEAREST);
            }

            // Load the bitmap into the bound texture.
            GLUtils.texImage2D(GLES20.GL_TEXTURE_2D, 0, bmp, 0);

            // Recycle the bitmap, since its data has been loaded into OpenGL.
            if (!keepInMemory) {
                bmp.recycle();
            }
        }

        if (textureHandle[0] == 0)
        {
            throw new RuntimeException("Error loading texture.");
        }

        this.setExternalId(textureHandle[0],GLES20.GL_TEXTURE_2D);
        return textureHandle[0];
    }
}
One could use the CustomTexture constructor from any Thread but the CustomTexture#loadTexture(boolean,boolean) method needs to be called from the GLThread.
This implementation is kinda very simple and it doesn't cover all of jPCT-AE's texture features (and it probably isn't really (easily) possible to have texture manipulation/effects like jPCT-AE supports them out of the box). However, the uploading process seems much faster using this method too. Also, this could potentially solve memory issues if you have them.

Now, I did say you could use near nothing in JVM RAM, so what about the Bitmap that is passed to this CustomTexture?
Well, as since Android 8.0, you can load Bitmap's immediately into the hardware-level (probably GPU..?), meaning that the Bitmap is not stored in the JVM RAM.
That is if you use Bitmap.Config.HARDWARE when you decode your image file (from resources, online of file): https://developer.android.com/reference/android/graphics/Bitmap.Config#HARDWARE.
Unfortunately, jPCT-AE does not seem to support Bitmap's that have been created using this Config, because of the immutability and inaccessibility of the Bitmap pixels.
However, but the CustomTexture class would work with Bitmap's that are using this Config.

I hope this could be useful for someone someday.
Feel free to give your thoughts and ideas

Cheers,
Abiram

Alright, thank you. I figured it'd not make a big difference but I mostly wondered if this was intentional so I guess not.

About the ideal batch size, I have found Config.glBatchSize=3000 to be pretty ideal in my use cases when the vertex count for the Object3D is smaller than about 100000. The Config.glBatchSize needs to be further decreased when your Object3D has higher vertexcount. But this different per Object3D structure again...

In my use case the distance between vertices does become smaller for higher vertexcount... I don't know if that could be a problem that the vertices become more dense. I have noticed a stronger drop for the needed glBatchSize for higher polygoncount UV-spheres than for higher polygoncount ico-spheres.

And regarding why the normal rendering doesn't show 'defects' when Object3D#forceGeometryIndices() is enabled?

I've noticed now that it perhaps is defects in the generated model, and I wonder if Object3D.addTriangle works by adding triangles that are not adjacent to other triangles (so basically floating triangles)
Also, does it matter in what order you define the 3 vertices anti clockwise.
Is there a difference between v3 -> v2 -> v1 and v1 -> v3 -> v2?

Because I seem to get lines in my wireframe model which I don't think I have defined

I don't...