Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - AeroShark333

Pages: [1] 2 3 ... 15
Support / Re: Increase number of texture units
« on: August 02, 2020, 08:58:02 pm »
Okay, thank you for looking into it :)
I'd be interested in hearing the results.

I'm not entirely sure what you meant with the memory usage thing..? I believe it'd be possible to test it with one single texture assigned to 8 texture layers too. (Not really useful in practice but I guess it's easiest to test)

Projects / Re: my project - Vehicle Simulation
« on: August 02, 2020, 11:57:22 am »
Nice particle effects 8)

Support / Re: Increase number of texture units
« on: August 01, 2020, 09:05:57 pm »
No idea what that error should be. Something isn't quite right with the gl state for some reason. I would ignore it for now.
Okay, thank you

And yes, 4 is a hard coded limit. I looked into expanding it once, but decided against it for reasons that I can't remember anymore. Must have been a technical limitation of some kind. There's no way to hack around it, I'm afraid.
I found this post (Reply #1) for a possible reason why:
Another possible reason I could think of: the minimum amount of vertex attributes is used up.

But I still think it should be possible to increase the limit to at least 8; especially modern devices (I think actually old ones too) should support this.
It is true that vertex shaders have very limited textures to access (minimum of 0).
Though, usually I believe textures are only accessed in the fragment shader (so there should be no problem at all considering the limit for the amount of vertex shader textures).
The amount of textures that can be accessed in the fragment shader is at least 8.

To fix the vertex attributes being used up: merge variables into one bigger variable.
Currently there's 4 texture attributes for the texture coordinates (as seen in:
However, these are all vec2's, while they could be vec4's.
4 vec4's could potentially hold texture coordinates for 8 texture stages.
Code: [Select]
attribute vec4 texture01;
void main(){
    vec2 texture0 = texture01.xy;
    vec2 texture1 =;

According to the OpenGLES2 spec: (page 66 of documentation; page 71 of PDF)
StateMinimum value

I suppose it'd be a quite a challenge to be rewriting this so I'm not sure if it's too much to ask for.
I'd have wanted to give it a shot if jPCT-AE was open-source but yeah...
Otherwise, would it be possible to add something more hacky so I'd still be able to bind these textures to the Object3D (and its GLSLShader) from stage 5 to 8?
A TextureBindingHook or something for additional texture stages, something like:
Code: [Select]
TextureInfo blah ... // first 4 textures go here

obj.setTextureBindingHook(new TextureBindingHook(){
    public void beforeFinishedBinding(){
        Texture tex = fifthTex;
        int stage = 5;
        String variableName = "textureUnit4";
        methodToBind(tex, stage, variableName);
(Additional texture coordinates attributes I don't really need; but only being able to access the textures in the fragment shader)

Support / Increase number of texture units
« on: July 29, 2020, 06:55:13 pm »
I received a crash from an user with the following stacktrace:
Code: [Select]
  at com.threed.jpct.Logger.log (
  at com.threed.jpct.GL20.checkError (
  at com.threed.jpct.GL20.glGenBuffers (
  at com.threed.jpct.CompiledInstance.compileToVBO (
  at com.threed.jpct.CompiledInstance.render (
  at com.threed.jpct.GLRenderer.drawWireframe (
  at com.threed.jpct.World.draw (
  at com.threed.jpct.World.drawWireframe (
  at com.aeroshark333.artofearthify.lw.ArtOfEarthify$ (
  at com.aeroshark333.artofearthify.utils.WorkerThread$ (
  at com.aeroshark333.artofearthify.lw.ArtOfEarthify.onDrawFrame (
  at com.aeroshark333.artofearthify.lw.LiveWallpaperRenderer.onDrawFrame (
  at android.opengl.GLSurfaceView$GLThread.guardedRun (
  at android.opengl.GLSurfaceView$ (
Any idea what this could be? I've only received this once so maybe it could be ignored...

PS: The question is unrelated to the original thread but I thought the topic title suited... so...

PPS: Although jPCT has Config.maxTextureLayers, the hard limit seems to be 4. Would it be possible to increase this value to 8 (or arbitrary)? Or assign these extra textures using a hack or something? I'd like to be able to access 8 textures in my fragment shader in a single pass

From my own experience:

Pro's shaders:
Shaders are fastest

Con's shaders:
Shaders can produce inconsistent results on different devices
Writing shaders for animations is more complex than creating Java animations

Support / Re: relationship between Object3D and Light
« on: June 03, 2020, 04:23:31 pm »
I already had a slight feeling the IRenderHook stage was too late for light manipulation...

A solution that might work (depending on your scenario) if your main character is always fully visible and nothing is between the camera plane and the main character, is to create a second World with identical Camera but with an additional Light on top of the already existing Lights. And to render and draw this second main character World after the original World... But I guess this would seem like a bit of a hack.

I don't think jPCT-AE allows the shader variables of the default shader to be manually altered. But I believe this would maybe be one of the easier changes for jPCT that would allow for light manipulation since I suppose the default shader is based on a GLSLShader already anyway. E.g. setting diffuseColor to black or something when it's off. Though, I guess you wouldn't be sure which of the 8 lights is the 'reflection light' if the sorting of the lights array is distance based or based on in which order it got added to the world. But I believe it's something you could calculate then. I guess this solution would need 'getters' though in the GLSLShader class and access to the default shader.

Or maybe the LightingHook is even easier...

Support / Re: relationship between Object3D and Light
« on: June 03, 2020, 07:04:24 am »
Perhaps in your situation you could copy and modify the default shader a little to your expectations. It kind of would allow light-manipulation per Object3D once you apply these custom GLSLShaders to different Object3D's. But perhaps a little too complex solution...

Another solution might be to add an IRenderHook to your Object3D's and enable/disable lights in beforeRendering/afterRendering. But I'm not sure if this would work and I'm not sure if this is too great for performance. But in my head, I believe it'd allow for per Object3D (per polygon even...) light manipulation.

To avoid GL context loss, you might want to use GLSurfaceView#setPreserveEGLContextOnPause(true);

Otherwise you'll need to recreate the framebuffer and the textures would need to be re-uploaded like MichaelJPCT said

Support / Re: Minor blitshader bug
« on: April 23, 2020, 07:59:02 pm » remains a mystery to me. All I've added is setting a flag that reenables some vertex buffers that shouldn't have been disabled in the first place. long as it works now.
Yeah, I guess this solution will do :)
I'll see if I can get rid of these transparant blits as well

Thank you both for helping

Support / Re: Minor blitshader bug
« on: April 23, 2020, 07:21:58 pm »
Ok, I've updated 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).

Support / Re: Minor blitshader bug
« on: April 23, 2020, 03:52:58 pm »
I'm not sure about this. Actually, I don't even understand my comment from back then anymore. Because, if you set a new blitting shader, buffered blits are executed anyway. I don't see why you should still need this dummy texture hack. fb.display() executes stored blits as well, but it also does something more. It shouldn't really hurt to use it, but I fail to see why it helps in this case. I've uploaded a new jar that adds a new method to FrameBuffer called flushBlittingPipeline() which does what it says. Maybe you can try to use that in addition or in replacement of the dummy texture blit and see if that helps.

As MichealJPCT suggested, flush() or sync() might be worth a try. There's an undocumented config switch to enable those for blitting. Set Config.blittingMode  to 9 for a flush(), to 10 for a sync() and to 11 for both and see, if that helps. I doubt it, but there has to be a reason why I put those in there...

Edit: looking at the code, these config values only enable sync() and flush() BEFORE the actual blitting. If you want to execute them afterwards as well, just add a 4 to these values.
I first downloaded the jar from the jPCT downloads page but I guess that wasn't the right new jar...
So I used that beta link later (from another thread): which did have the FrameBuffer#flushBlittingPipeline()
I'm not sure if the dummy blit helps anything but I believe it did help to push the shadered blits. I guess it doesn't do any harm anyway but yeah, not ideal I suppose.

Anyway, back to the multiple (shadered) blits:
Using FrameBuffer#flushBlittingPipeline() after the having blitted using the first shader doesn't work
I tried to use FrameBuffer#sync() before too but it didn't work. I haven't tried FrameBuffer#flush() before yet but it also didn't really work.
The blittingMode's 9, 10, 11, 13, 14 and 15 all didn't work.
So far only using FrameBuffer#display() seems to work...
But I believe the idea of having multiple FrameBuffer#display() calls in one draw call isn't how it's intended to be..?

Support / Minor blitshader bug
« on: April 23, 2020, 12:20:58 am »

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]

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.blit(...); // <- Dummy-blit (1x1 transparent pixel with some other texture or something)

Now in my case, I use:
Code: [Select]
fb.blit(...); // <- Dummy-blit (1x1 transparent pixel with some other texture or something)
fb.blit(...); // <- Dummy-blit (1x1 transparent pixel with some other texture or something)
fb.blit(...); // <- Dummy-blit (1x1 transparent pixel with some other texture or something)

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


Support / Re: [Tips] Huge texture uploading (memory tricks)
« on: April 09, 2020, 04:40:24 pm »
BTW: Do you mind if I add this to the wiki?
I don't mind, it was meant to be written to help out other people for their future projects anyway :)

Support / [Tips] Huge texture uploading (memory tricks)
« on: April 03, 2020, 08:52:58 pm »

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):
Code: [Select]
package com.aeroshark333.artofearthify.utils;

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) {

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

        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):
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 :)


Projects / Re: my project - Vehicle Simulation
« on: March 19, 2020, 01:11:59 pm »
I believe you're using circles as some kind of base for these cloud particles? And you're having a multiple of these circles for each cloud, I guess?
And then applying them with a random filter (in shader?) so it creates these pixel holes so it looks more cloudy.
I guess the color is either white (top) or gray (bottom).

I believe it'd look better with even smaller circle particles but it'd be heavy for devices I suppose...

Pages: [1] 2 3 ... 15