www.jpct.net
jPCT-AE - a 3d engine for Android => Support => Topic started by: EgonOlsen on May 13, 2011, 11:17:08 pm
-
What about the new version, any new info? :)
I had two evenings to spare and started working on it. My idea is to implement it in a way that it appears as ES 1.1 to the engine, so that jPCT's actual renderer needs no big changes and one codebase can serve both worlds. So far, it's working fine...but there's no support for anything else than one layer of opaque textures for now, no lighting, no fog, no nothing...
The test scene in all it's ES2.0 glory:
(http://www.jpct.net/img/gles20.png)
One bugger: Because of Google's stupidity http://code.google.com/p/android/issues/detail?id=8931 (http://code.google.com/p/android/issues/detail?id=8931), it doesn't work with anything below 2.3...at least not if you intend to use VBOs. I'm not sure what Dalvik does if methods are used in a compiled class that are never called, so maybe it'll work in 2.2 too but without VBOs...i'll care about that at a later time...
-
I look forward to further information and news :)
-
I splitted the new version topic into this thread. It's about the current state of OpenGL ES2.0 support due to popular demand.
-
It's now stable enough to run An3DBenchXL...it works fine, but it looks awful, because i'm still using my very basic default shader which supports virtually nothing but simple texturing.
Therefor, the benchmark results have to be taken with a grain of salt, because neither the fully featured shader nor the Java code for processing lights, fog and material are in place right now. It scored ~30000 points while the OpenGL ES1.1 version scores ~27500 points...but with much more gpu features used, so this will change. But at least it's not slower for now... ;)
-
An update: Ambient color and additional color as well as transparency and blitting seem to work fine now...
-
I hope that I will see some public beta version in near future :)
-
Will take some time. I still have to mimic OpenGL's lighting stuff in both Java and GLSL code for example. That's not that easy...
-
I know, that you have a lot of work, but will be here support for spotlights and shadows? will be the same as desktops jPCT? :)
-
My first goal is to make it behave like jPCT-AE when run on ES 1.x...that's difficult enough. Then, i'll open the shader support to anyone (just like desktop jPCT does, but maybe in a different way). What you do with the shaders...well, that's up to you. I'll open the default shader as well, so you are free to fiddle around with it. Concerning shadows, shaders alone don't cut it. You'll need to be able to render into the depth buffer...that's another story...
-
Shaders on mobile devices..LOL! I thought that it might be a good idea to implement some phong lighting instead of the fixed function pipeline's vertex lighting...not good. The per-pixel operations needed for this kill performance. With only four lights, you are down to one digit fps numbers on the Nexus S..back to good old gouraud shading, i guess...
-
So spot light is not good for performance?
-
Not per pixel at least...
-
Lighting seems to work fine so far...
(http://www.jpct.net/img/gles20_2.png)
-
Fog works fine, too. With that, everything works that is required to make Alien Runner look as it should when using OpenGL ES 2.0. This is it:
(http://www.jpct.net/img/gles20_al.png)
-
Some performance figures taken from the Nexus S. These are from An3DBenchXL. The tests are all running fine, just the multi-texturing in the Ninja test isn't supported right now, so it will get worse...
Using the OpenGL ES 1.1 path:
05-25 23:29:24.995: INFO/jPCT-AE(6997): Double dragon: 30.55 fps
05-25 23:29:24.995: INFO/jPCT-AE(6997): Flower power: 22.86 fps
05-25 23:29:24.995: INFO/jPCT-AE(6997): Ninjas' garden: 16.14 fps
05-25 23:29:24.995: INFO/jPCT-AE(6997): Emperor's new clothes: 43.58 fps
05-25 23:29:24.995: INFO/jPCT-AE(6997): Magic island: 37.33 fps
05-25 23:29:24.995: INFO/jPCT-AE(6997): TOTAL SCORE: 26053
Using the OpenGL ES 2.0 path:
05-25 23:25:07.137: INFO/jPCT-AE(6940): Double dragon: 9.25 fps
05-25 23:25:07.137: INFO/jPCT-AE(6940): Flower power: 21.52 fps
05-25 23:25:07.137: INFO/jPCT-AE(6940): Ninjas' garden: 13.61 fps
05-25 23:25:07.137: INFO/jPCT-AE(6940): Emperor's new clothes: 42.26 fps
05-25 23:25:07.137: INFO/jPCT-AE(6940): Magic island: 19.59 fps
05-25 23:25:07.137: INFO/jPCT-AE(6940): TOTAL SCORE: 18394
Why is that? Well, as you can see, high polygon tests (dragon and island) suffer the most. I guess that's because a high polygon count means a high vertex count, which means a lot of calls to the vertex shader. The most expensive part of the vertex shader is the lighting, because it requires some dot-products, which seem to be slow. If you remove the light source from the tests, it runs much faster...
So..well...this is a bit disappointing, but i actually expected something like this. Too bad, that you can't mix shaders and fixed function as you can with desktop OpenGL.
-
What is interesting is, that devices like the LG P999, that are using the NVidia Tegra 2 GPU instead of the common PowerVR, suck at these high polygon tests too when compared to PowerVR chips (all running with 1.1 of course). That might be an indicator that the PowerVR chips still have dedicated hardware for the fixed function pipeline while the NVidia haven't. Just a guess, but it seems reasonable to me...
-
eh,can you open up the source code of some of the above?They look very nice. :o
-
Oh, I did not expected so bad result... is there any chance to optimalization?
-
Not much IMHO. One can try to tweak the shader once its finished, but don't expect any miracles...
-
eh,can you open up the source code of some of the above?They look very nice. :o
Both are open. You'll find that tree scene on AE's projects page and the Alien Runner sources can be found in the Alien Runner thread.
-
There's a fix for missing OpenGL ES 2.0 bindings. It uses NDK.
-
Yes, i know. But i'm not going to support this, because you can't cover both ways with one code base. I would rather add a way to support the libgdx binding instead, but i haven't decided this yet.
-
Glad to hear you are working on the OpenGL ES 2.0 stuff , have been away from working on my Android stuff, but will get back to it in a few. I just have Android 2.2, but the hardware/software supports 2.0. I have not gotten to use that part of it yet though. Waiting on you :)
-
Almost everything is in place now. Default shader as well as user defined ones seem to work fine so far (the rock is using a user defined "all red" shader in this shot):
(http://www.jpct.net/pics/gles20_3.png)
-
Current performance...
06-01 22:56:51.968: INFO/jPCT-AE(15332): Double dragon: 11.11 fps
06-01 22:56:51.968: INFO/jPCT-AE(15332): Flower power: 16.33 fps
06-01 22:56:51.968: INFO/jPCT-AE(15332): Ninjas' garden: 11.60 fps
06-01 22:56:51.968: INFO/jPCT-AE(15332): Emperor's new clothes: 42.10 fps
06-01 22:56:51.968: INFO/jPCT-AE(15332): Magic island: 18.60 fps
06-01 22:56:51.968: INFO/jPCT-AE(15332): TOTAL SCORE: 17270
-
good work :) ... but frame rate is very low :( is it normal in whole ogl2? and do you plan implement shadows (real-time as well as pre rendered)? :)
-
I can only speak for my phone/gpu (Nexus S/PowerVR SGX 540) and on that device, using shaders for everthing IS a lot slower than using the fixed function pipeline. On the other hand, you have to keep in mind that An3DBenchXL is really stressing polygon count in some tests. When running the less demanding original An3DBench, the difference is much less. I'm still looking for ways to improve this though, but i don't expect much from what i've read so far.
Concerning shadows: As said, this will require to render the depth map into a texture. This isn't supported ATM. I think, i'm going to see how adoption rate of 2.0 really is once i release it and decide based on that. The current problem with ES 2.0 ATM is (IMHO), that the API is ahead of the hardware. Even multi-texturing is MUCH slower when using shaders than it is when using the fixed function pipeline. At least on the SGX 540...i'm still looking for information on how many shader pipelines this sucker really has...
-
shadows: but for example glbenchmark 2.0 running with soft shadows and also old quake4droid (ogl1) support shadows... and two examples running with shadows if you download GL ES SDKs (http://www.imgtec.com/PowerVR/insider/sdk/KhronosOpenGLES2xSGX.asp)
but highest priority has optimalization (if is possible), because fps are very low...
-
shadows: but for example glbenchmark 2.0 running with soft shadows and also old quake4droid (ogl1) support shadows... and two examples running with shadows if you download GL ES SDKs (http://www.imgtec.com/PowerVR/insider/sdk/KhronosOpenGLES2xSGX.asp)
but highest priority has optimalization (if is possible), because fps are very low...
I never said anything against shadows... ??? Btw, OpenGL ES 1.x can't do texture based shadows. So what quake4droid does there can only be stencil shadows, which are more or less a dead end. Concerning some magic optimization...i don't expect them to be found. You have to keep in mind that the tests that are hurt the most are really high polygon. Nobody uses such scenes on mobile device ATM. The dragon scene renders around 55.000 polygons, which means that the vertex shader has to process 165.000 vertices, i.e. it calculates 165.000 dot products for the lighting calculations alone...that simply takes its time.
-
Mine incomplete scene has something around 12500 tris, but many will not be added. So I hope, that will be fast in ogl2, running 55fps now, but without textures... what about portals? :) it can much improve frame rate :)
-
I scrapped portal rendering for the Android version of jPCT. It was great for doing software rendering where fillrate was very limited but it doesn't play very nice on GPUs. In addition, at least the tile-based renderers like the PowerVR and Adreno GPUs that are used in most mobile device (i.e. everything not Tegra) won't benefit from it anyway, because the way in which they work already reduces overdraw of opaque polygons to 0.
-
Did some heavy debugging to make the default shaders work on Adreno GPUs (like the Nexus One uses it). The shader compiler of these things doesn't seem to like any kind of loop inside the shader as it creates either bogus results or kills the device. Actually, it doesn't seem to like anything inside the shader, because it's soooo slow in executing the default shaders. Performance of the 2.0 pipeline is around 1/10th of the performance of the 1.1 pipeline. Many thanks to raft for his patience....he had to execute billions of test cases for me to make this work. Looking at the performance, i'm not sure that it was worth it...
Edit: Managed to improve this...see below.
-
Current performance:
06-08 21:34:28.437: INFO/jPCT-AE(907): Double dragon: 12.77 fps
06-08 21:34:28.437: INFO/jPCT-AE(907): Flower power: 18.92 fps
06-08 21:34:28.437: INFO/jPCT-AE(907): Ninjas' garden: 17.70 fps
06-08 21:34:28.437: INFO/jPCT-AE(907): Emperor's new clothes: 42.39 fps
06-08 21:34:28.437: INFO/jPCT-AE(907): Magic island: 20.74 fps
06-08 21:34:28.437: INFO/jPCT-AE(907): TOTAL SCORE: 19483
I've splitted the fragment shader into three separate ones now to avoid dynamic branching in the shader in some cases.
-
More separation (of the vertex shaders this time) and i decided to use the unrolled loop that i was using for Adreno gpus only for all...it's ugly looking (code wise), but it's faster...result:
Nexus S
2.0
06-08 22:43:40.511: INFO/jPCT-AE(1643): Double dragon: 40.11 fps
06-08 22:43:40.511: INFO/jPCT-AE(1643): Flower power: 19.39 fps
06-08 22:43:40.511: INFO/jPCT-AE(1643): Ninjas' garden: 17.35 fps
06-08 22:43:40.511: INFO/jPCT-AE(1643): Emperor's new clothes: 40.87 fps
06-08 22:43:40.511: INFO/jPCT-AE(1643): Magic island: 26.95 fps
06-08 22:43:40.511: INFO/jPCT-AE(1643): TOTAL SCORE: 25051
edit:
1.1 again for comparison
05-25 23:29:24.995: INFO/jPCT-AE(6997): Double dragon: 30.55 fps
05-25 23:29:24.995: INFO/jPCT-AE(6997): Flower power: 22.86 fps
05-25 23:29:24.995: INFO/jPCT-AE(6997): Ninjas' garden: 16.14 fps
05-25 23:29:24.995: INFO/jPCT-AE(6997): Emperor's new clothes: 43.58 fps
05-25 23:29:24.995: INFO/jPCT-AE(6997): Magic island: 37.33 fps
05-25 23:29:24.995: INFO/jPCT-AE(6997): TOTAL SCORE: 26053
Nexus One
2.0
I/jPCT-AE ( 2928): Double dragon: 4.43 fps
I/jPCT-AE ( 2928): Flower power: 8.54 fps
I/jPCT-AE ( 2928): Ninjas' garden: 2.40 fps
I/jPCT-AE ( 2928): Emperor's new clothes: 33.19 fps
I/jPCT-AE ( 2928): Magic island: 6.06 fps
I/jPCT-AE ( 2928): TOTAL SCORE: 9457
1.1
I/jPCT-AE (16793): Double dragon: 11.86 fps
I/jPCT-AE (16793): Flower power: 15.86 fps
I/jPCT-AE (16793): Ninjas' garden: 2.38 fps
I/jPCT-AE (16793): Emperor's new clothes: 36.23 fps
I/jPCT-AE (16793): Magic island: 15.63 fps
I/jPCT-AE (16793): TOTAL SCORE: 14192
-
...and please don't ask why the double dragon test on Nexus S is actually faster than under 1.1....i've no idea....
-
excellent, come on :)
-
Anybody listening with too much time and a NVidia Tegra based device?
-
BLARGH...PowerVR's shader compiler isn't much better than Qualcomms...on my phone, i get bogus results in one shader once i store a value in a temporary variable. If i access it directly, everything is fine. In another, really simple shader, i had to add two totally pointless lines with some assignments of vectors to variables that i never use...or otherwise, the resulting shader doesn't render anything...i'm having fun...!
-
Performance after the last minor shader tweaks:
06-09 23:36:07.476: INFO/jPCT-AE(6662): Double dragon: 41.46 fps
06-09 23:36:07.476: INFO/jPCT-AE(6662): Flower power: 20.18 fps
06-09 23:36:07.476: INFO/jPCT-AE(6662): Ninjas' garden: 17.07 fps
06-09 23:36:07.476: INFO/jPCT-AE(6662): Emperor's new clothes: 43.15 fps
06-09 23:36:07.476: INFO/jPCT-AE(6662): Magic island: 27.40 fps
06-09 23:36:07.476: INFO/jPCT-AE(6662): TOTAL SCORE: 25845
I thought about making the shader generation totally dynamic, i.e. the engine would write the shader source code by itself based on the demands of the renderer...but the bugs in the shader compilers prevent me from doing this.
-
Some more shader tweakage...
Nexus S:
INFO/jPCT-AE(16223): Double dragon: 42.14 fps
INFO/jPCT-AE(16223): Flower power: 20.64 fps
INFO/jPCT-AE(16223): Ninjas' garden: 17.42 fps
INFO/jPCT-AE(16223): Emperor's new clothes: 41.82 fps
INFO/jPCT-AE(16223): Magic island: 31.43 fps
INFO/jPCT-AE(16223): TOTAL SCORE: 26571
Nexus One:
I/jPCT-AE ( 3817): Double dragon: 13.79 fps
I/jPCT-AE ( 3817): Flower power: 10.84 fps
I/jPCT-AE ( 3817): Ninjas' garden: 2.38 fps
I/jPCT-AE ( 3817): Emperor's new clothes: 35.26 fps
I/jPCT-AE ( 3817): Magic island: 10.27 fps
I/jPCT-AE ( 3817): TOTAL SCORE: 12561
-
oh, some tests are even faster than 1.1, good work :) so is possible for performance perpixel lighting (spot light), bump maps? :)
-
It depends. The current implementation doesn't do much in the fragment shader, which is the most expensive part (because it's executed for each pixel). If you put a dot product there for some per-pixel stuff, performance will suffer and there's nothing i do can about that. My guess is, that it'll be ok to use it for some objects but to light the whole scene per pixel, current hardware is too weak IMHO.
-
(http://www.jpct.net/pics/gles20_n.png)
Ported my simple normal mapping shader to ES 2.0...finally, i saw a sense in the precision modifiers, because with lowp, the result was totally screwed up!?
We are getting close to a first alpha release of this version...
-
Found and fixed a bug when combining blitting with custom shaders only. A simple example:
(http://www.jpct.net/img/gles20_b.png)
The funny thing with this test case is, that performance hovers around 40fps unless you start to use the touch screen...then, it goes up to 56 fps (which is the device's limit). Seems like as if the really small load that this test puts onto the cpu makes the device reducing its clock speed or something...
-
Two light sources struggling for power:
(http://www.jpct.net/pics/gles20_b2.png)
This shows the same strange fps loss as the former test case while the cpu is more or less idle...
-
I'll postpone the first alpha release until i've added the option to assign additional vector data to an Object3D to allow (for example) for proper tangent vectors. Right now, i'm playing around with parallax mapping...
(http://www.jpct.net/img/gles20_o2.png)
Simple normal mapping
(http://www.jpct.net/img/gles20_o1.png)
The same thing with parallax mapping
-
looks nice, good work! :) ... how much time takes these shader demos on screenshots (render time)?
-
The upper left number is the fps counter. However, my phone tends to clock down if cpu load is low (which it is in these demos), so the frame rate in an actual game might be better.
-
Must...stop...creating...more...test cases....anyway, tangent vector calculation works fine now, but has to be optimized a little bit before release.
Parallax mapping can look cool:
(http://www.jpct.net/img/gles20_o3.png)
-
Made a small video of that one: http://www.youtube.com/watch?v=5Zgn1OCDIus (http://www.youtube.com/watch?v=5Zgn1OCDIus)
-
woooow, it is very nice :) I looking forward to public release :)
-
very impressive ;D
-
Anybody listening with too much time and a NVidia Tegra based device?
I meet these two requirements if it is still needed.
-
Yes, it is! ;D Could your please download this apk: www.jpct.net/download/tmp/An3DBenchXL.apk (http://www.jpct.net/download/tmp/An3DBenchXL.apk)!?
Then run it once using ES 1.1 and once using ES 2.0. The main question is, if the 2.0 version runs at all and if it looks similar to the 1.1 version. The benchmark results for both modes are interesting too, of course.
-
I am very curious, so I also had to try this app :) ... result is same as on your device... but lenses looks differently in 1.1 and 2.0
1.1
(http://2i.cz/2i/t/81462f05d6.jpg) (http://2i.cz/81462f05d6)
2.0
(http://2i.cz/2i/t/90573e14c7.jpg) (http://2i.cz/90573e14c7)
-
.. but lenses looks differently in 1.1 an 2.0
I've never noticed that...i'll have a look. Thanks for trying.
Edit: Lousy bug, that one. It's fixed now, but i won't update the benchmark's apk.
-
Ok, here you go: http://www.jpct.de/download/net/jpct-ae_124_alpha.zip (http://www.jpct.de/download/net/jpct-ae_124_alpha.zip)
It includes the OpenGL ES 2.0 support in it's current state but lacks some documentation. It also includes the APK shown in the video as an Eclipse project to get you started with ES 2.0.
If you want to fiddle around with the default shaders: They are included in the jar. You can simply extract and modify them for your own purpose if you like. Please keep in mind that they are pretty ugly to make them run on Adreno (i.e. unrolled loops and such).
-
With OpenGL ES 2.0, anti-aliasing becomes possible. This shows the difference (magnified by 2x):
Without AA:
(http://jpct.de/pix/no_aa.png)
With 2xAA:
(http://jpct.de/pix/ms_aa.png)
I'll add a custom config chooser to the util-package to ease usage.
-
I am very curious about what effect it will have on performance :) ... note, tegra 2 does not support anti-aliasing
-
Tegra 2 supports CSAA instead if MSAA...i can't test it for obvious reasons but it should be supported.
Edit: Performance impact depends on the gpu. On my Nexus S, performance is quite good. However, it doesn't really look like plain multi-sampling to me, because it also shows some effect on texture content (i.e. it somehow blurs transparent edges (fps counter) for example), which multi-sampling alone shouldn't do.
-
Hello what is the advantage of ES2.0 other than ability to anti alias? Is it better in terms of performance or memory? I guess it also allows shaders whereas the 1.1 didn't (I'm just guessing that since you posted a bunch of shader demos)?
-
Hello what is the advantage of ES2.0 other than ability to anti alias? Is it better in terms of performance or memory? I guess it also allows shaders whereas the 1.1 didn't (I'm just guessing that since you posted a bunch of shader demos)?
No, it's not better in terms of performance (albeit you can write your own, customized shaders that might improve some special cases) and not in terms of memory (it requires the memory for storing the shaders in addition, which isn't much though). It allows for AA and shaders...both features aren't available in 1.x. If it's worth it, depends on your needs.
-
any news about release next alpha with antialiasing? :)
-
Can do it anytime...i'll try to fix Disastorm's issue first and then it will come with that fix anyway.
-
New alpha has been uploaded. See "new version"-thread for details.
-
no slowdown FPS with AA in my game :) ... upper image is without AA and lower image is with, is it normal for blitted textures?
(http://2i.cz/2i/t/5ebbf2d80b.jpg) (http://2i.cz/5ebbf2d80b)
-
no slowdown FPS with AA in my game :) ... upper image is without AA and lower image is with, is it normal for blitted textures?
Yes. That's what i meant with:
...because it also shows some effect on texture content (i.e. it somehow blurs transparent edges (fps counter) for example)...
Edit: But it looks like as if you can get rid of this, if you disable filtering on the textures that are used for blitting.
-
It helped, thanks:)
-
how can I apply shaders like are depth of field or per pixel light? I will try find some on the Internet and test how the application will look like...
-
It's not THAT easy, i'm afraid. First of all, depth of field is a post processing effect. To apply a post processing effect in form of a shader, you have to render the whole scene into a texture and then onto a quad to display it, because neither in the fragment nor in the vertex shader you do have access to the framebuffer's data itself. At the moment, you can't really do this. You would need support for frame buffer objects (fbos) and maybe render the scene into different fbos splitted into color and depth buffer and such. Support for this is on my list, but not implemented yet.
Everything else (i.e. "normal" shader code that isn't used for full screen effects) is possible. However, as i've mentioned in my release-post, it..."lacks some documentation". What i meant with that is, that the engine has to know where to put which data into the shader, or otherwise, you wouldn't be able to access the vertices, normals, lights etc. in your shader. It does this by making you follow a naming convention when you write your shader and i haven't documented this naming yet...i'll do briefly now. The idea is this: If jPCT-AE finds any of the following uniforms or attributes in either shader part (vertex/fragment), it'll put the corresponding engine data in it. If it doesn't find one, it'll simply skip that data. Ok, here we go:
uniform mat4 modelViewMatrix; - The model view matrix, i.e. the matrix that makes the transformation from object into camera space
uniform mat4 modelViewProjectionMatrix; - The model view projection matrix, i.e. the model view matrix * project matrix
uniform mat4 textureMatrix; - The texture matrix
uniform vec4 additionalColor; - An object's additional color (stored in .rgb of the uniform).
uniform vec4 ambientColor; - The world's ambient color (stored in .rgb of the uniform).
uniform float alpha; - The alpha value of the object.
uniform float shininess; - The shininess if specular lighting is being used.
uniform bool useColors; - true, if the object contains additional vertex colors.
uniform float fogStart; - The depth coordinate, at which the fog starts. -1.0 if there is no fog.
uniform float fogEnd; - The depth coordinate of maximum fog.
uniform vec3 fogColor; - The fog color.
uniform int lightCount; - The number of lights that light this object.
uniform vec3 lightPositions[8]; - The light positions in camera space.
uniform vec3 diffuseColors[8]; - The diffuse color of each light source.
uniform vec3 specularColors[8]; - The specular color of each light source.
uniform sampler2D textureUnit0; - The texture sampler for the first texture layer.
uniform sampler2D textureUnit1; - The texture sampler for the second texture layer.
uniform sampler2D textureUnit2; - The texture sampler for the third texture layer.
uniform sampler2D textureUnit3; - The texture sampler for the forth texture layer.
uniform int textureCount; - The number of texture layers.
uniform int blendingMode[4]; - The blending modes between these layers (0==MODULATE, 1==ADD, 2==REPLACE, 3==BLEND).
attribute vec4 position; - The vertex positions in object space.
attribute vec3 normal; - The vertex normals in object space.
attribute vec4 color; - The additional vertex colors (if any).
attribute vec4 tangent; - The tangent vectors. The presence of this attribute in a shader's source code will trigger the tangent vector calculation when calling build().
attribute vec2 texture0; - The texture coordinates for the first stage.
attribute vec2 texture1; - The texture coordinates for the second stage.
attribute vec2 texture2; - The texture coordinates for the third stage.
attribute vec2 texture3; - The texture coordinates for the forth stage.
Any additional uniforms can be given to the shader via the methods in GLSLShader. Currently, it's lacking the option to feed additional vertex attributes into the shader, but for most cases, this shouldn't be needed. If it is, consider to store them in a texture instead.
As you can see, you can't simply copy and paste shaders from the internet, because you have to make them use this naming convention. In addition, the least shaders that can be found are written for OpenGL ES. Most are written for "normal" OpenGL...and "normal" OpenGL is different in a way that it already has access to some pre-defined attributes and uniforms like gl_NormalMatrix, gl_Normal, gl_Vertex, gl_LightSource etc.... If you want to port such a shader, you first have to find out which pre-defined attribute/uniform matches which in jPCT-AE or maybe you have to set it from the outside in your code.
As said, you'll find the default shader set in the jar and an example shader of a different kind in the HelloShader-example.
-
Thanks, I never wrote any shaders, so I start with some tutorials. Have you any advice where should I look?
-
I'm not sure...any shader tutorial for OpenGL ES should do, as long as it's good. It doesn't have to be Android specific. You'll most likely have more luck with tutorials for the iPhone. The syntax is the same...just keep in mind that on iPhone, there's only PowerVR while on Android, a lot of different implementations exist.
-
Are you planning to implement pixel light and spot light into engine? I think that more people will use it :)
-
I might add some shaders of that kind, but i'm not going to add it as a core functionality.
-
I copy fragment point light from this (http://www.learnopengles.com/android-lesson-three-moving-to-per-fragment-lighting/) page, but boxes are black. Is it ok?
uniform mat4 modelViewProjectionMatrix;
uniform mat4 modelViewMatrix;
attribute vec4 position;
attribute vec4 color;
attribute vec3 normal;
varying vec3 v_Position;
varying vec4 v_Color;
varying vec3 v_Normal;
void main()
{
v_Position = vec3(modelViewMatrix * position);
v_Color = color;
v_Normal = vec3(modelViewMatrix * vec4(normal, 0.0));
gl_Position = modelViewProjectionMatrix * position;
}
precision mediump float;
uniform vec3 lightPositions[8];
varying vec3 v_Position;
varying vec4 v_Color;
varying vec3 v_Normal;
void main()
{
float distance = length(lightPositions[0] - v_Position);
vec3 lightVector = normalize(lightPositions[0] - v_Position);
float diffuse = max(dot(v_Normal, lightVector), 0.1);
diffuse = diffuse * (1.0 / (1.0 + (0.25 * distance * distance)));
gl_FragColor = v_Color * diffuse;
}
package cz.test.point_light;
import java.lang.reflect.Field;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;
import android.app.Activity;
import android.content.pm.ActivityInfo;
import android.content.res.Resources;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
import android.view.MotionEvent;
import android.view.Window;
import android.view.WindowManager;
import android.view.WindowManager.LayoutParams;
import com.threed.jpct.Camera;
import com.threed.jpct.FrameBuffer;
import com.threed.jpct.GLSLShader;
import com.threed.jpct.Light;
import com.threed.jpct.Loader;
import com.threed.jpct.Logger;
import com.threed.jpct.Object3D;
import com.threed.jpct.Primitives;
import com.threed.jpct.RGBColor;
import com.threed.jpct.SimpleVector;
import com.threed.jpct.Texture;
import com.threed.jpct.TextureManager;
import com.threed.jpct.World;
import com.threed.jpct.util.AAConfigChooser;
import com.threed.jpct.util.BitmapHelper;
import com.threed.jpct.util.MemoryHelper;
/**
* @author EgonOlsen
*
*/
public class Point_light_testActivity extends Activity {
private static Point_light_testActivity master = null;
private GLSurfaceView mGLView;
private MyRenderer renderer = null;
private FrameBuffer fb = null;
private World world = null;
private RGBColor back = new RGBColor(50, 50, 100);
private float touchTurn = 0;
private float touchTurnUp = 0;
private float xpos = -1;
private float ypos = -1;
private Object3D cube0 = null;
private Object3D cube1 = null;
private Object3D cube2 = null;
private Object3D cube3 = null;
private Object3D dummy = null;
private int fps = 0;
private Light light;
protected void onCreate(Bundle savedInstanceState) {
Logger.log("onCreate");
if (master != null) {
copy(master);
}
requestWindowFeature(Window.FEATURE_NO_TITLE);
getWindow().setFlags(LayoutParams.FLAG_FULLSCREEN, LayoutParams.FLAG_FULLSCREEN);
getWindow().setFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON, WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);
super.onCreate(savedInstanceState);
setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE);
mGLView = new GLSurfaceView(getApplication());
super.onCreate(savedInstanceState);
mGLView = new GLSurfaceView(getApplication());
mGLView.setEGLContextClientVersion(2);
mGLView.setEGLConfigChooser(new AAConfigChooser(mGLView));
renderer = new MyRenderer();
mGLView.setRenderer(renderer);
setContentView(mGLView);
}
@Override
protected void onPause() {
super.onPause();
mGLView.onPause();
}
@Override
protected void onResume() {
super.onResume();
mGLView.onResume();
}
protected void onStop() {
super.onStop();
}
private void copy(Object src) {
try {
Logger.log("Copying data from master Activity!");
Field[] fs = src.getClass().getDeclaredFields();
for (Field f : fs) {
f.setAccessible(true);
f.set(this, f.get(src));
}
} catch (Exception e) {
throw new RuntimeException(e);
}
}
public boolean onTouchEvent(MotionEvent me) {
if (me.getAction() == MotionEvent.ACTION_DOWN) {
xpos = me.getX();
ypos = me.getY();
return true;
}
if (me.getAction() == MotionEvent.ACTION_UP) {
xpos = -1;
ypos = -1;
touchTurn = 0;
touchTurnUp = 0;
return true;
}
if (me.getAction() == MotionEvent.ACTION_MOVE) {
float xd = me.getX() - xpos;
float yd = me.getY() - ypos;
xpos = me.getX();
ypos = me.getY();
touchTurn = xd / -100f;
touchTurnUp = yd / -100f;
return true;
}
try {
Thread.sleep(15);
} catch (Exception e) {
// No need for this...
}
return super.onTouchEvent(me);
}
protected boolean isFullscreenOpaque() {
return true;
}
class MyRenderer implements GLSurfaceView.Renderer {
private long time = System.currentTimeMillis();
private boolean stop = false;
public MyRenderer() {
}
public void stop() {
stop = true;
}
public void onSurfaceChanged(GL10 gl, int w, int h) {
if (fb != null) {
fb.dispose();
}
fb = new FrameBuffer(w, h);
if (master == null) {
world = new World();
world.setAmbientLight(0, 0, 0);
Texture texture = new Texture(BitmapHelper.rescale(BitmapHelper.convert(getResources().getDrawable(R.drawable.icon)), 64,
64));
TextureManager.getInstance().addTexture("texture", texture);
dummy = Object3D.createDummyObj();
cube0 = Primitives.getCube(10);
cube0.rotateY(-(float) Math.PI / 4f);
cube0.rotateMesh();
cube0.clearRotation();
cube0.calcTextureWrapSpherical();
cube0.setTexture("texture");
cube0.strip();
cube0.build();
cube1 = cube0.cloneObject();
cube2 = cube0.cloneObject();
cube3 = cube0.cloneObject();
world.addObject(cube0);
world.addObject(cube1);
world.addObject(cube2);
world.addObject(cube3);
cube0.translate(-20, -20, 0);
cube1.translate(20, -20, 0);
cube2.translate(-20, 20, 0);
cube3.translate(20, 20, 0);
cube0.addParent(dummy);
cube1.addParent(dummy);
cube2.addParent(dummy);
cube3.addParent(dummy);
Object3D plane = Primitives.getPlane(40, 3);
plane.translate(0, 0, 10);
plane.build();
world.addObject(plane);
Resources res = getResources();
GLSLShader pointLight = new GLSLShader(Loader.loadTextFile(res.openRawResource(R.raw.vertex_point_light)),
Loader.loadTextFile(res.openRawResource(R.raw.fragment_point_light)));
cube0.setShader(pointLight);
cube1.setShader(pointLight);
cube2.setShader(pointLight);
cube3.setShader(pointLight);
//plane.setShader(pointLight);
light = new Light(world);
light.setPosition(new SimpleVector(20, 0, -1));
light.setIntensity(255, 255, 255);
Camera cam = world.getCamera();
cam.moveCamera(Camera.CAMERA_MOVEOUT, 100);
MemoryHelper.compact();
if (master == null) {
Logger.log("Saving master Activity!");
master = Point_light_testActivity.this;
}
// Logger.setLogLevel(Logger.DEBUG);
}
}
public void onSurfaceCreated(GL10 gl, EGLConfig config) {
}
public void onDrawFrame(GL10 gl) {
try {
if (!stop) {
if (touchTurn != 0) {
dummy.rotateY(touchTurn);
touchTurn = 0;
}
if (touchTurnUp != 0) {
dummy.rotateX(touchTurnUp);
touchTurnUp = 0;
}
light.rotate(new SimpleVector(0, 0, 0.01), new SimpleVector());
fb.clear(back);
world.renderScene(fb);
world.draw(fb);
fb.display();
if (System.currentTimeMillis() - time >= 1000) {
Logger.log(fps + "fps");
fps = 0;
time = System.currentTimeMillis();
}
fps++;
} else {
if (fb != null) {
fb.dispose();
fb = null;
}
}
} catch (Exception e) {
Logger.log(e, Logger.MESSAGE);
}
}
}
}
-
color isn't set by jPCT-AE unless you specify some vertex color, which is why it's always black. Try to set it fixed to white or something. I tried that with your code, but the result still looks kind of strange. So i've modified the shader slightly and set the light source to -20 instead of -1 (because otherwise, it's inside the cubes).
I created this:
uniform mat4 modelViewProjectionMatrix;
uniform mat4 modelViewMatrix;
attribute vec4 position;
attribute vec4 color;
attribute vec3 normal;
varying vec3 v_Position;
varying vec4 v_Color;
varying vec3 v_Normal;
void main()
{
v_Position = vec3(modelViewMatrix * position);
v_Color = vec4(1,1,1,1);
v_Normal = vec3(modelViewMatrix * vec4(normal, 0.0));
gl_Position = modelViewProjectionMatrix * position;
}
precision mediump float;
uniform vec3 lightPositions[8];
varying vec3 v_Position;
varying vec4 v_Color;
varying vec3 v_Normal;
void main()
{
float distance = length(lightPositions[0] - v_Position);
vec3 lightVector = normalize(lightPositions[0] - v_Position);
float diffuse = dot(v_Normal, lightVector);
diffuse = diffuse * (10.0 / distance);
gl_FragColor = v_Color * diffuse;
}
...still not very convincing IMHO, but it might be a starting point. You might as well look out for a simple phong shader instead. I had one lying around here, but i can't find it ATM... :(
-
thanks, getting color from vertex is bad solution, but I never wrote any shader, so I need some parts of code to understand how it works :)
-
Any release date for the new version of jPCT-AE supporting OpenGLES 2.0 ?
++
dherby
-
here (http://www.jpct.de/download/net/jpct-ae_124_alpha.zip) you can download new alpha more than month...
-
Thks for the info. I've already had this version who's working fine but I'm still undecided about the right engine for me.
In fact, I'm looking for a game engine with bone and pose animation support. I've tested jme3.0, libgdx and jPCT. All are good engine but jPCT+bone seems to be the more simple and suitable for my needs.
I've tested all of them with a modified simbad ogre3D model (I've added simple keyframe for lipsync animation).
Here are the result in FPS with a Galaxy S/android 2.3.4 (Bone:"Dance" Anim + Keyframe Blending).
- libgdx 15FPS (GLES 2.0)
- jme3.0 10FPS (GLES 2.0)
- jpct-ae 20 FPS (GLES 1.1)
In addition, I've implemented my own library in C + NDK android for managing pose frame and keyframe animations natively in opengl ES 2.0 (Only one vertex shader computing Bone Position and Keyframe position at the same time).
It's working pretty well and it's fast (approx 30-35FPS) but some optimization are chipset dependent (Power VR) and It's a nightmare to deal with OpenGL graphic context (LiveWallPaper), moreover, I've got some nasty compatible issue with a few smart-phone.
So, I need to come back the right path using only android SDK. Do you think I can expect some FPS improvement with the new GLES 2.0 implementation of jPCT-AE ?
Thks !
++
dherby
-
FPS most likely won't increase with ES 2.0. It might happen, if you write yourself some dedicated shaders that do only what you need. jPCT-AE's OpenGL ES 2.0 support relies on some default shaders, which might not be optimal in all cases.
Edit: You might get an increase if you would do the skinning in the shader, what Bones doesn't do. Somebody (not me... ;) ) would have to modify Bones for that. I'm not sure, if it's worth it though. You can also try to use the libgdx-support of jPCT-AE (see the wiki)...it might help to increase vertex upload time, but i wouldn't expect too much (if anything) on a current device.
-
OGLES 2.0 mode in and3Dbench xl running on HTC sensation :)
-
That's an Adreno 220 gpu, right?
-
yes, I will try also on Samsung Galaxy S2 with Mali-400, but I do not when...
-
I've already ran it myself on an S2. It worked except for some texture problems with non-square textures, but that's a common issue with ES 2.0, which is why jPCT-AE already prints out a warning in this case.
-
I have a Tegra 2 tablet running homeycomb 3.1, let me know if you need to test GL20 routines. I also own a DesireHD running 2.3.5 if that's any help. I also have access to a new OMAP tablet.
edit: An3DBenchXL is working fine on that hardware.