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
1
Support / Re: Increase number of texture units
« on: August 12, 2020, 10:41:52 pm »
Haven't tried it yet. I'm busy with other stuff ATM, but I'll come to it eventually.
Oh okay, take your time ;)
Also, good luck :D

I'm really curious to hear the results so excuse me being a little impatient

2
Support / Re: trying to get default shader code
« on: August 12, 2020, 10:34:09 pm »
I think you need to set the shader locator before being able to use it... It probably throws a NullPointerException as a crash now. I'm not sure how this entirely works in the first place either...

I think there should be a way to still access the default shader code. I believe because these shader files are in the base of the jar library, they'd also go to the base of the apk file. I think you should be able to use these shader text files from there.

I believe the best way to alter the default shaders is to re-use them by copying.
That means to extract the jPCT-AE jar using a zip-extractor like WinRAR or something. In here you can find the shaders in plain text.
Copy two shaderfiles (vertex+fragment), which you need, to your Android project.
You can edit these text files and load them into a new GLSLShader as you want.

3
Support / Re: Increase number of texture units
« on: August 08, 2020, 10:04:12 pm »
Any luck..?

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

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

6
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: http://www.jpct.net/forum2/index.php?topic=3371.0
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: http://www.jpct.net/jpct-ae/doc/com/threed/jpct/GLSLShader.html)
However, these are all vec2's, while they could be vec4's.
4 vec4's could potentially hold texture coordinates for 8 texture stages.
Example:
Code: [Select]
//VERTEX SHADER
...
attribute vec4 texture01;
...
void main(){
    ...
    vec2 texture0 = texture01.xy;
    vec2 texture1 = texture01.zw;
    ...
}

According to the OpenGLES2 spec: https://www.khronos.org/registry/OpenGL/specs/es/2.0/es_cm_spec_2.0.pdf (page 66 of documentation; page 71 of PDF)
StateMinimum value
MAX VERTEX TEXTURE IMAGE UNITS0
MAX TEXTURE IMAGE UNITS8
MAX VERTEX ATTRIBS8

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.setTexture(blah);

obj.setTextureBindingHook(new TextureBindingHook(){
    @Override
    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)

7
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]
java.lang.RuntimeException:
  at com.threed.jpct.Logger.log (Logger.java:206)
  at com.threed.jpct.GL20.checkError (GL20.java:163)
  at com.threed.jpct.GL20.glGenBuffers (GL20.java:1385)
  at com.threed.jpct.CompiledInstance.compileToVBO (CompiledInstance.java:1478)
  at com.threed.jpct.CompiledInstance.render (CompiledInstance.java:606)
  at com.threed.jpct.GLRenderer.drawWireframe (GLRenderer.java:2552)
  at com.threed.jpct.World.draw (World.java:1424)
  at com.threed.jpct.World.drawWireframe (World.java:1132)
  at com.aeroshark333.artofearthify.lw.ArtOfEarthify$34.run (ArtOfEarthify.java:1492)
  at com.aeroshark333.artofearthify.utils.WorkerThread$2.run (WorkerThread.java:46)
  at com.aeroshark333.artofearthify.lw.ArtOfEarthify.onDrawFrame (ArtOfEarthify.java:1681)
  at com.aeroshark333.artofearthify.lw.LiveWallpaperRenderer.onDrawFrame (LiveWallpaperRenderer.java:73)
  at android.opengl.GLSurfaceView$GLThread.guardedRun (GLSurfaceView.java:1553)
  at android.opengl.GLSurfaceView$GLThread.run (GLSurfaceView.java:1253)
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

8
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

9
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...

10
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.

11
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

12
Support / Re: Minor blitshader bug
« on: April 23, 2020, 07:59:02 pm »
Ok...it 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. Well...as 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

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

14
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): http://jpct.de/download/beta/jpct_ae.jar 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..?

15
Support / Minor blitshader bug
« on: April 23, 2020, 12:20:58 am »
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:
Code: [Select]
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

Pages: [1] 2 3 ... 15