www.jpct.net
jPCT-AE - a 3d engine for Android => Support => Topic started by: EgonOlsen on March 28, 2010, 09:47:50 pm
-
As long as jPCT-AE is still in alpha stage, i'll post changes in this thread.
-
New version uploaded with better support for 16bit textures. It now determines if 4bpp or 5/1 is the better choice, so that it can use a higher color accuracy on textures that don't need 4bits of alpha.
-
alway nice to see updates :P
-
I've updated the jar with a new version that includes the ability to unload textures via the TextureManager. The renderer already supported this, i just missed to port the methods in TextureManager. This is fixed now, happy unloading...
-
And another update with slightly higher blitting performance and a new method (Texture.keepPixelData(<boolean>)).
-
cool, there seem to be %10-15 blitting performance increase ;D
-
Yes, it uses indexed geometry now, which reduces vertex uploads to the GPU by 25% but adds maintaining the additional indices. 10-15% is quite ok as a result.
-
Uploaded a new jar version with greatly improved animation and blitting performance as well as a moderately improved overall performance.
-
awesome. there is about 50% fps increase at bones ninja demo ;D
so how is this happened, profiling miracle ?
note: apk (http://www.aptalkarga.com/bones/Bones-Android-Ninja.apk) is up to date
-
While still doing the calculations in floating point, i'm sending the results converted to fixed point to the GPU now. While this makes no difference at all if you do it one by one, it largely improves performance when doing it in batch, i.e. instead of transfering float[]s into native memory, i'm now using int[]s. I really don't understand why this is the case. I would have expected the floats to be copied without any changes from VM to native memory but that doesn't seem to be the case somehow.
One ninja animates @18fps now, two at @10, three @6 on my phone now.
Edit: The increase doesn't come from rendering the scene itself, because static geometry doesn't improve that much (not even 10%), so it has to be the data transfer. My MD2 test case now runs at 54 fps instead of 26 and my blitting test at 44 instead of 12. Considering that i started with 4fps for that MD2 with the initial release, this is not too bad...
-
quite impressive indeed ;D
very similar results on G1. 17, 10, 6 fps with 1,2,3 ninjas. 26, 16, 11 fps when converted to keyframe meshes. here is the apk (http://www.aptalkarga.com/bones/Bones-Android-Ninja2.apk). definetely a boost
so i suppose you dont cast floats to ints, but use Float.floatToIntBits(..) or Float.floatToRawIntBits(..) method ?
i wonder how this will perform on nexus one ? maybe dl.zerocool may test it if he's around ;)
-
Nope, it's a cast. I'm using this floatToIntBits() in some other locations like the normal calculations but not here.
-
However, i somehow have to add support for float[] back in, because int[]s are too limiting in some situations. I just have to find a good way to do it without hurting performance of the int[]s...
-
i see. so model scale should be appropriate.
-
Another update, now with the option to revert to floating point. Object3D has a new method (setFixedPointMode(<boolean>)) for this, default is true. If set to false, vertex data will use floating point again. The rest remains in fixed point, i.e. animations will still run faster than before...just not as fast as with fixed point only.
-
Really happy to see all this updates :)
-
built-in mesh animations are much faster now, compared to bones. do they make calculations as ints ?
-
No, nothing has changed in the animation code.
-
oops. bones is quite expensive for Android in that case. i've made a test, animated ninja with bones but didnt apply the animation with IVertexController. results are 19, 11, 7 fps for 1,2,3 ninjas on G1. when animation applied fps's were 17, 10, 6
great job for increasing vertex upload performance ;D
bones definetely need a JIT ::)
-
Another update! This one increases performance for lighting and/or more complex scenes with different objects up to 10%. My demo scene runs @31fps instead of 28fps now on my phone. In addition, it contains some minor tweaks for Matrix and SimpleVector math (but nothing to get crazy about...you'll hardly notice it).
-
Great, I don't see much difference since I'm working at 30 or 60fps depending if I'm using the camera or not. (With the Nexus One)
But it's always nice to see such improvement.
But it does improve the fps on the Samsung Spica, the latest update made the fps go from 5 to 20~ so it's really great :)
I just wanted to ask if it's possible to next release to add in front of functions that throw any exception
the code throws Exception or Better throws SpecificException .
This really would help to Dev/Debug and avoid exceptions randomly uncaught that make the program FC.
-
Wow...what an improvement on the Spica. How comes that? Must have done something that its renderer really likes...
About the exceptions: There are basically two groups...one that thinks that checked exceptions are a good thing and one that doesn't. I belong to the second, which is why i'm using unchecked exceptions for almost everything. For a brief discussion about pros and cons, just search for Bruce Eckel's view on this.
As far as AE is concerned, wrapping the resource loading and maybe the actual rendering into a try-catch should catch most of the common problems. Things like matrix math and similar doesn't throw any exceptions on its own.
-
This low end phones are definitely built with no standard.
About exception, I'll take a look when I'll have time at what you told me, but at moment I can't.
I understand and respect your point of view, so I'll continue using without throws.
Another question is, are you sure that TextureManager flush works correctly ? Because sometimes I got the error :
04-14 14:26:52.923: ERROR/AndroidRuntime(4318): java.lang.RuntimeException: [ Wed Apr 14 14:26:52 Europe/Zurich 2010 ] - ERROR: A texture with the name 'grassy' has been declared twice!
Here is how I do things:
gameModels.add(new GameModels(Primitives.getPlane(20, 30), new Texture(
resources.openRawResource(R.raw.planetex))));
textureManager.addTexture("grassy", gameModels.get(0).modelTexture);
gameModels.get(0).model.setTexture("grassy");
private class GameModels
{
public GameModels(Object3D model, Texture modelTexture)
{
this.model = model;
this.modelTexture = modelTexture;
}
public Texture modelTexture;
public Object3D model;
}
Is there something wrong ?
-
I'll look into that TextureManager-thing...
-
flush() should work fine. It discards all internal structures of the TextureManager. There's no chance that some texture remains in the manager after calling flush. Maybe you are adding the texture twice without calling flush() in between?
-
Another small update with some additional micro optimizations. On my phone, the demo scene increases by 3%, the MD2 animation by 5%.
-
Yeah another update :P
About the Textures : Certainly, anyway I'm no more using textures so it's not the problem, thank you for the check :)
I'm using materials instead. It's enough for what I'm doing at moment.
-
Hello,
I didn't find a way to check if all the models are build and ready to draw.
Is it possible to implement this feature ? So we will be able to do a loading screen (while the resources are being loaded).
Thank you.
Best Regards
"A returned value would be great for example"
I don't know if you threaded your buildObject that's why I'm asking for it.
-
I'm not sure how this should work. The only that knows if all resources have been loaded is the application that loads them, isn't it?
-
So your functions aren't threaded.
That's what I was asking :).
I found a solution so, just start the loading screen before starting loading the models, then after all loads and builds stop it.
;)
I do that in a thread and the animation screen is a thread too.
Thank you.
ps: sorry lately I've not been answering quite fast, but I'm overloaded at school with projects and tests, it's the end of my 2nd year of engineer in 7weeks...
So I've been very busy.
-
Nope, nothing is threaded there. If it returns, the model is already loaded.
-
You told me that nothing was threaded, but it's strange, because I've a method initialize that I do use to load all objects
The first one from the Loader.Load3DS
then I reuse the Object3D meshes in my classes that inherit Object3D with the calling of super(obj, true);
I'm know looking at logcat, I just printed a System out in the end of my initialize method.
and it ends before all meshes are compiled.
On spica :
05-27 13:45:16.488: INFO/jPCT-AE(6389): Object 8/Bee2 compiled to 5 subobjects in 580ms!
05-27 13:45:16.778: INFO/jPCT-AE(6389): Subobject of object 9/Bee3 compiled to fixed point data using 1236 vertices in 157ms!
05-27 13:45:16.828: INFO/jPCT-AE(6389): Subobject of object 9/Bee3 compiled to fixed point data using 306 vertices in 49ms!
05-27 13:45:16.893: INFO/jPCT-AE(6389): Subobject of object 9/Bee3 compiled to fixed point data using 600 vertices in 65ms!
05-27 13:45:16.893: INFO/jPCT-AE(6389): Subobject of object 9/Bee3 compiled to fixed point data using 12 vertices in 3ms!
05-27 13:45:16.953: INFO/jPCT-AE(6389): Subobject of object 9/Bee3 compiled to fixed point data using 204 vertices in 56ms!
05-27 13:45:16.953: INFO/jPCT-AE(6389): Object 9/Bee3 compiled to 5 subobjects in 464ms!
05-27 13:45:17.618: INFO/System.out(6389): End initialisation
05-27 13:45:17.953: INFO/jPCT-AE(6389): Subobject of object 10/Bee4 compiled to fixed point data using 1236 vertices in 823ms!
05-27 13:45:18.428: INFO/jPCT-AE(6389): Subobject of object 10/Bee4 compiled to fixed point data using 306 vertices in 459ms!
05-27 13:45:19.333: INFO/jPCT-AE(6389): Subobject of object 10/Bee4 compiled to fixed point data using 600 vertices in 861ms!
05-27 13:45:19.338: INFO/jPCT-AE(6389): Subobject of object 10/Bee4 compiled to fixed point data using 12 vertices in 2ms!
05-27 13:45:19.723: INFO/jPCT-AE(6389): Subobject of object 10/Bee4 compiled to fixed point data using 204 vertices in 343ms!
05-27 13:45:19.838: INFO/jPCT-AE(6389): Object 10/Bee4 compiled to 5 subobjects in 2884ms!
And other objects continue compiling after that.
So apparently there's a thread compiling them.
I don't understand T_T
Thank you in advance.
-
That's because compilation happens on first access in onDrawFrame...and onDrawFrame runs in another thread than the rest of the Activity. jPCT-AE doesn't spawn any threads.
-
Ho... thank you and sorry to disturb.
But so, is it possible to know when compilation is over? Or is it possible to compile before drawing?
-
The decision to compile at draw time was based on the desktop version, that requires this. The AE version doesn't, which is why i've uploaded a new version that adds a compileAllObjects(<FrameBuffer>); to World. Hope this helps. In addition, i've improved the object compiler itself, so that compile times are down to 30% on my phone.
-
Awesome, thank you so much ! :) You are always responding to my questions.
I needed this because I wanted to have a loading screen.
It's quite annoying to have the user/player seeing a simple ui without any models shown because not yet compiled.
And the IA of the objects where started too soon due to the same problem.
So yes, that was exactly what I needed. :)
I'm sorry that I haven't ask this sooner but this was not my job in the project... But apparently one of my teammates didn't worked at all.
And what he did was totally wrong, calling Loader.Load3DS each time he created a new object !!!
That's why I never saw the problem coming... So I'm quite stressed lately to have something functional.
Thank you for your help again :) (Very precious !)
-
It worked like a charm !
Just had to make the game wait until frameBuffer is made available.
(I create frameBuffer inside the onScreenChanged, because I need w,h for buffer as phones do not have the same w,h screen :P )
[EDIT]
WOOOO !!!
I didn't look at compiling time.
05-27 22:12:04.297: INFO/jPCT-AE(12492): Subobject of object 89/Bear9 compiled to fixed point data using 12 vertices in 0ms!
05-27 22:12:04.308: INFO/jPCT-AE(12492): Subobject of object 89/Bear9 compiled to fixed point data using 732 vertices in 8ms!
05-27 22:12:04.328: INFO/jPCT-AE(12492): Subobject of object 89/Bear9 compiled to fixed point data using 1674 vertices in 23ms!
05-27 22:12:04.338: INFO/jPCT-AE(12492): Subobject of object 89/Bear9 compiled to fixed point data using 228 vertices in 4ms!
1 full object took around 30-40 ms ! on the nexus.
with the last version of course it was really fast compare to spica but around 50-100ms.
-
Another question is it really necessary to run strip on models after build ?
I would like to know if there's an improvement, I can't find where to see how much RAM my app is allocating so I can't really test if it's better or not :(
-
It should be better and it's actually pretty cheap, so there's no reason not to strip unless you need access to the stripped data (some methods in PolygonManager do).
-
WOOOO !!!
I didn't look at compiling time.
....
1 full object took around 30-40 ms ! on the nexus.
with the last version of course it was really fast compare to spica but around 50-100ms.
Dalvik's slowness and aversion to object creation and especially garbage collection sometimes makes you think of some very strange solutions to improve things. That's what happened to the compiler here.
-
I do agree Dalvik do react very very strangely.
[Edit]
Okay so I'll use strip since I don't use any of the polygon methods on my objects.
-
I do agree Dalvik do react very very strangely.
I'm still working on the compiler, because its performance is crucial for startup time. The old version compiled my high polygon beethoven on the Samsung Galaxy in 30 sec., the uploaded version needs 13 secs, my current development version is down to 6 secs... ;D
-
Sound really nice !
-
Uploaded a new version that includes some additional optimizations for the compiler. It's around 5-6 times faster and uses much less memory and creates much less garbage than before the optimizations. However, there's still some work to do for animated objects to compile faster.
-
Another small update that adds the compiler optimizations for animated objects.
-
Another update that adds the option to create Textures out of Drawables instead of Bitmaps, improves loading speed of serialized objects and reduces memory usage during the deserialization process. I've also updated the JavaDOCs.
-
And another small update that reduces memory usage of deserialized instances of Animation and that is more aggressive when calling Object3D.strip(), i.e. it frees more memory.
Edit: And working with lights is a bit cheaper now due to some internal instance recycling, i.e. less gc occurs. There still seems to be some part that creates some garbage related to lights, but i still have to find it... ???
-
Nice work :)
-
Hi, with the last JPCT I've out of memory errors on magic & spica.
Does it consume more memory ?
-
No, actually it consumes much less than before. When exactly do the errors occur?
-
When I compile the model -> call of -> WORLD.compileAllObjects
The objects are really small.
~2,4ko the first 3ds file and another of 2,8ko
but I do clone the first one 7 times and the other one 23times.
Perhaps it comes from there.
-
If the models share the same mesh, you should also do a Object.shareCompiledData(<Object3D>); on all the clones to make them use the same compiled data. That will increase compilation time and decreases memory usage. However, i don't see why this should take more memory than before. Actually it should require less to compile them now. I'll look into it anyway to make sure that i haven't introduced something that may cause this problem.
-
Maybe you were calling strip() after calling compileAllObjects()? In that case, the stripping doesn't happen. I've uploaded a new version that fixes this. In addition, it reduces object creation for bill boarded objects and reduces memory usage of compiled object by a negligible amount. Apart from that, i don't see any change that i've made that could cause the compile to fail where it formerly succeeded...quite the contrary.
Edit: Decreased memory usage while compiling some more....
-
Okay thank you :)
I'm going to test it on emulator for now and on magic tomorrow, It's a friend phone
so I don't always have it.
Oh I forgot to mention, you can search on market for " ARescue " It's my application.
I'm not sure it will run properly, sounds are deactivated at moment.
It's quite slow, and collisions make the game freeze (FC) sometimes so don't flood the bees or the superBees.
-
It crashes from time to time at startup on my Galaxy. I can't tell the reason, i've no access to the logs right now. Maybe that's that memory thing? When it runs, it's really really slow. Why is it so slow? Is the time spend in the engine or in your code?
-
I can't tell the reason, i've no access to the logs right now.
The application "Android System Info" has a nice log function. Its free.
-
Cool little app!
One issue with the game seems to be that you are not using the
mGLView.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {
public EGLConfig chooseConfig(EGL10 egl, EGLDisplay display) {
// Ensure that we get a 16bit framebuffer. Otherwise, we'll fall
// back to Pixelflinger on some device (read: Samsung I7500)
int[] attributes = new int[] { EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_NONE };
EGLConfig[] configs = new EGLConfig[1];
int[] result = new int[1];
egl.eglChooseConfig(display, attributes, configs, 1, result);
return configs[0];
}
});
part like the demo code does. This means, that it runs in software emulation on my phone, which it obviously does (judging from the log its using Pixelflinger, which is Androids software renderer).
In addition, it spams the log with "superbee0died" or similar albeit i haven't done anything except moving the phone. I'm not sure if this is an issue, i was just wondering about it.
Haven't got the crash yet...
-
Ok, it's out of memory indeed...try to convert your files to OBJ-format instead. The 3DS loader is pretty stupid and consumes too much memory while parsing. I have to work on this. Until then, please give the obj-format a try if possible.
-
Cool, I'm going to test all the things you told me.
But I can't use this init (see the attached file):
mGLView.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {
public EGLConfig chooseConfig(EGL10 egl, EGLDisplay display) {
// Ensure that we get a 16bit framebuffer. Otherwise, we'll fall
// back to Pixelflinger on some device (read: Samsung I7500)
int[] attributes = new int[] { EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_NONE };
EGLConfig[] configs = new EGLConfig[1];
int[] result = new int[1];
egl.eglChooseConfig(display, attributes, configs, 1, result);
return configs[0];
}
});
Because it show something very odd, I attached a screenshot to this
[attachment deleted by admin]
-
Looks strange indeed. Does it happen without using the camera too? If this init code isn't there, you'll never get hardware acceleration on the Galaxy...might not be much of an issue though, because it's not very popular.
-
always happens T_T, it's certainly due to something else, but I don't know what.
-
Doesn't happen in my demos, does it? How is that overlay done?
-
Another update: The greedy 3ds-loader behaves better now.
-
No it didn't happen with your demo.
So in theory it comes from my app.
I added my layout and another class with opengl init etc.
[attachment deleted by admin]
-
and the render.
[attachment deleted by admin]
-
No idea...my guess would be that this has something to do with the alpha channel your frame buffer uses. You can try to specify one like so:
{ EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_ALPHA_SIZE, <1 or 4 or 8...just try one>, EGL10.EGL_NONE }
No idea if this helps...
-
You rock !
with 1 I couldn't initialize the render but with 2 everything works.
I'm sorry to ask but I don't understand exactly what it does so can you explain me ?
Since I'm studying software engineering I really would like to know what I'm doing :P
-
I'll upload soon the changes you will tell me if it works better ;)
-
published
-
It's using the hardware now on the Galaxy...but when using the camera, it looks pretty much like in your screen shot. When not using the camera, i can see the overlay but no 3d graphics at all. Maybe you should try to disable the transparency related stuff completely when not using the camera.
-
Working much better now :)
Quite hard to play when starting but after a while I was able to win with 640 points
-
I've published a new version.
with 8 as param, it should work, with and without camera on Spica.
Let me know if works for you too, and it's the hardware acceleration.
-
Working much better now :)
Quite hard to play when starting but after a while I was able to win with 640 points
Ahahaha, I know, I'm always extremely busy, so I can't provide update now.
It's the end of the year and I'm very busy, exams in 2 weeks and other projects to finish...
So I'm quite sorry because it's buggy.
-
I'll give it a try later...my battery is down... :'(
-
^^
I've found this :
http://code.google.com/events/io/2009/sessions/WritingRealTimeGamesAndroid.html
He does give some great tips.
-
Works with hardware and correct graphics on the Samsung now, if using the camera. If not, i still don't see any graphics except for the overlay. With camera, it's faster than in software mode of course, but still not really playable.
I suggest to place a single light source above the honey pot to make the graphics look more 3d-ish.
-
I'm adding the light at moment, but how can I suppress the all APLHA thing ?
-
Okay so I changed the pixelformat from my translucent to opaque
and when using no camera
I config the screen in this way :
glSurface.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {
public EGLConfig chooseConfig(EGL10 egl, EGLDisplay display) {
// Ensure that we get a 16bit framebuffer. Otherwise, we'll fall
// back to Pixelflinger on some device (read: Samsung I7500)
int[] attributes = new int[] { EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_NONE };
EGLConfig[] configs = new EGLConfig[1];
int[] result = new int[1];
egl.eglChooseConfig(display, attributes, configs, 1, result);
return configs[0];
}
});
And then the camera works fine, but with no camera I've the layering problem, lik there was 2 screens with a blue filter T_T
-
Thans for the idea with the lights ;) I added 3 of them it look so much better.
I also found what I asked you for :
http://www.khronos.org/opengles/documentation/opengles1_0/html/eglChooseConfig.html
Everything is explained here ;) So no need to explain.
-
New version of the ARescue and ARescueFroyo uploaded.
Tell me if it's better ;)
-
Lighting really improves the look. But there's still nothing to see when using the no-camera mode on the Galaxy.
-
Really strange, because I removed all the transparent stuff and initialize glSurface with the config you told me to.
-
I've found this :
http://code.google.com/events/io/2009/sessions/WritingRealTimeGamesAndroid.html
He does give some great tips.
What an awful sound recording...sounded like the borg from Star Trek in some parts. However, i liked the idea of adding a sleep to the input callback to avoid motion event flooding. Apart from that, he didn't offer anything new to me.
-
Really strange, because I removed all the transparent stuff and initialize glSurface with the config you told me to.
No idea. Might have something to do with that overlay or with clearing the framebuffer with an actual alpha value even if none is supported or whatever...Galaxy is a bit pissy regarding the gl drivers or so it seems. The pro side of this is, that if it runs fine on the Galaxy, it should run fine almost everywhere... ;D
-
I've found this :
http://code.google.com/events/io/2009/sessions/WritingRealTimeGamesAndroid.html
He does give some great tips.
What an awful sound recording...sounded like the borg from Star Trek in some parts. However, i liked the idea of adding a sleep to the input callback to avoid motion event flooding. Apart from that, he didn't offer anything new to me.
Ahaha ! I totally agree about the sound, I just read the subtitles ;) I didn't listen it.
Well yes, he don't give that much advices and most of them are "logic" that we already apply.
But I like that Google is little by little doing this kind of videos and tutorials, so we can expect better products to come to our phone.
-
Posted a new version should consume less cpu.
I don't really know why the game is so slow on certain phones T_T
-
Gave it another try and it does actually render the graphics in both modes correctly. It just seems to have a problem with the controls, so that the scene jumps out of the view field within a fraction of a second (yes, i did calibrate...) when making a subtle move. That made me think that there was nothing being rendered.
-
You're right we do have problems with controls. As you can see the scene don't stop jumping and moves are not smooth. I would like to repair those ASAP.
Thank you for testing :)
-
Do you have any idea why It could be so slow on some devices ?
Because I've reviewed again and again my code and I can't find what's wrong T_T
Can it come from the collision detections ?
Or perhaps just from the 3D rendering... I'm quite lost, and I don't find any tool that can examine what's time consuming.
I really would like to make it smooth on all cell phones.
But apparently that's impossible.
-
I'm quite lost, and I don't find any tool that can examine what's time consuming.
you can profile your android app within eclipse
-
What do you mean by profile (Does it mean examine ? sry my mother tongue is French & Portuguese) , and how can I do that ?
Have you a link to some tutorial or some explanation about it ?
[Edit]
I can't share yet the source code, but it will be shared soon as an Google project available trough svn.
But I need firstly to made the presentation to my classroom with my classmates and co-workers.
Because teachers judge us on the presentation and until then the code remains the school property.
And then I'll have my annually exams so I'll be very short in time to do this things.
But everything, included all resources will be shared asap.
-
right, profiling (http://en.wikipedia.org/wiki/Profiling_(computer_programming)) is analysing the program while running.
in eclipse, open the android devices tab (window|show view|other|android|devices) and you will see profiling options there. your phone need to be connected to your computer
-
Okay is on the DDMS view, I already use this,
but it only profiles the memory, objects created etc..
What I would like is to see which function is time consuming on CPU.
Which functions are called too often.
Without having to print each time I make a call...
-
I'm going to use this to view what is time consuming :)
Thank you for the word "profile / profiling" the only know I knew was profiler... who in my head is more related
to police tv shows... It's much more easy to find answer to my questions now.
http://developer.android.com/guide/developing/tools/traceview.html
-
but it only profiles the memory, objects created etc..
What I would like is to see which function is time consuming on CPU.
it gives the function times in detail ???
indeed it generates the same report in your post. but without the need to invoke any code..
-
I'm still using the 1.5 SDK/plugin...and i can't find any useful profiling option in that device tab... ???
-
that's weird ??? we are talking about the same plugin for eclipse 3.5, right ?
http://developer.android.com/sdk/eclipse-adt.html
maybe it's only available for linux ?
here is a screenshot:
(http://img132.imageshack.us/img132/8223/screenshotdebugmivgamee.th.png) (http://img132.imageshack.us/i/screenshotdebugmivgamee.png/)
-
Yes, that one. But as said, i'm still using the 1.5 version because it was difficult enough to make it work with Samsung and don't want to have to do it again right now. This is all there is:
(http://www.jpct.net/pics/plugin.png)
-
mm, but AFAIK the plugin is not bound to any SDK version..
-
No idea, but the ddms (which i'm usually using) in the SDK distribution offers exactly the same options. Anyway, i don't miss it much...profiliers are for the weak... ;D
-
if you say so.. chances arent that good but you may be missing the opportunity to double the performance ;D
-
Unlikely... ;)...but maybe i'm going to give the new SDK a go on another machine when i find the time. I just don't want to lose phone support on my main machine, which is why i'm a but more cautious with upgrading than usual. It was a pain in the arse to get the USB connection to the phone working, because the driver isn't really good...it might have been improved, if the new SDK provides it's own driver for the Galaxy (which the old didn't), but i'm not sure about this...
-
why not give linux (ubuntu for instance) a try ? it was a matter of plug and play with G1.
-
The G1 is a matter of plug and play on Windows too...the Samsung needed some drivers from Samsung that were difficult to install. Linux isn't really an option for me. I tried it several times, installed Ubuntu for friends of mine and such and i just can't stand Linux on the desktop.
-
Another update that makes VBOs behave nicer and that fixes a flaw in the object compiler that caused too many Integer-instances being created where actually none were needed.
-
Uploaded a new version with a slightly more aggressive behaviour of the strip()-method and the option to assign a transformation matrix for the texture on stage 0 to an Object3D. However, the latter doesn't work on my phone (just like environment mapping). The Galaxy seems to have a problem with changing the texture matrix...it works all fine in the emulator though.
-
Great work :)
-
New version with a bugfix for calcMinDistance methods. I've also updated the Javadocs.
-
New version with less object creation inside of some methods. With this, my newest prototype game doesn't create any noticable garbage in the engine while running the main game.
It's becoming a kind of racing game and looks like this (pre-alpha with placeholder art...more like a test case for now). It runs @ 25fps on my crappy Samsung:
(http://www.jpct.net/img/alienrunner.png)
-
It runs @ 25fps on my crappy Samsung:
Nice one. Any demo to test?
-
Not yet...it's just too pre alpha... ;)
-
With this, my newest prototype game doesn't create any noticable garbage in the engine while running the main game.
can you please give some numbers ?
my game was reporting ~20.000 freed objects per ~5 seconds (4000/sec) on emulator :o i couldnt really find where this much came from.
i've tried some experimental things. for example replaced
if (tile.isHighlighted()) {
object3d.setAdditionalColor(JConfig.COLOR_TILE_HIGHLIGHT);
} else {
object3d.clearAdditionalColor();
}
with
if (highlighted != tile.isHighlighted()) {
highlighted = tile.isHighlighted();
if (highlighted) {
object3d.setAdditionalColor(JConfig.COLOR_TILE_HIGHLIGHT);
} else {
object3d.clearAdditionalColor();
}
}
this dropped gc to ~30.000 objects per ~15 seconds (2000/sec) ??? so almost cut gc in half.
may it be that such methods accidentally create temporary objects ?
-
Opps...clearAdditionalColor() in AE did create a new black color every call. It's fixed now, i've uploaded a new jar.
Currently, i've one gc in around 30-60 secs and that comes mostly from touch events and such. If you are using touch events, this tip is worth a look: http://www.jpct.net/wiki/index.php/Performance_tips_for_Android#Silence_the_touch_events (http://www.jpct.net/wiki/index.php/Performance_tips_for_Android#Silence_the_touch_events)
There are still a lot of methods that aren't optimized for really (if any) low object creation in AE. I only started working on one when i got a problem. So if you do (like with the color stuff), please let me know.
-
New version uploaded which fixes transparency. Former version always applied full alpha regardless of the setting of setTransparency(). This change may cause the trees in the demo source code become almost invisible...i'll correct that later.
-
New version with a fix for converting alpha textures to 16bit and some other, minor stuff.
-
that's weird ??? we are talking about the same plugin for eclipse 3.5, right ?
http://developer.android.com/sdk/eclipse-adt.html
maybe it's only available for linux ?
on ubuntu profile option is available in Eclipse when Nexus One is attached. since zerocool can't see it in windows, i suppose this is a linux (only ?) feature
-
New version, which hopefully fixes some transparency issues on N1.
-
And another version with some micro optimizations, less matrix multiplications and better state management....i hope, that i haven't screwed up anything... ;)
-
cool ;D 5-10% increase on my N1. the higher the object count the bigger the increase, because of matrix calculations i suppose.
yes, i saw that in trace view too, so profiling is not all for weak ;)
-
Debugging is for the weak, not profiling...you got that wrong... ;)
I've updated the jar again. Please this version too. It reduces GL state changes some more.
-
No idea, but the ddms (which i'm usually using) in the SDK distribution offers exactly the same options. Anyway, i don't miss it much...profiliers are for the weak... ;D
huh, you got yourself wrong ;D
anyway, thanks for the updates, this one is not recognizable with my game..
-
I think i somehow mixed up profiler with debugger when writing this... ;D
-
anyway, thanks for the updates, this one is not recognizable with my game..
Maybe because your game doesn't use many different textures?
-
BTW: If matrix multiplications are a performance problem, try to enable lazy transformations (Object3D.enableLazyTransformations()); whenever possible. Even if objects aren't really static but don't move within each frame, enable it and call touch() on the object once it actually moves. That might help to save a lot of matMuls depending on the scene.
-
I think i somehow mixed up profiler with debugger when writing this... ;D
yeap, as i said you got yourself wrong ;D
Maybe because your game doesn't use many different textures?
i guess so. in that scene there are only 6 object textures + 6 blit textures
BTW: If matrix multiplications are a performance problem, try to enable lazy transformations (Object3D.enableLazyTransformations()); whenever possible. Even if objects aren't really static but don't move within each frame, enable it and call touch() on the object once it actually moves. That might help to save a lot of matMuls depending on the scene.
thanks, that's a good tip :)
-
i guess so. in that scene there are only 6 object textures + 6 blit textures
I see...i've around 15 object textures and 5 blit textures and it does help a little. Nothing to get crazy about though. Maybe i should start a rant about why OpenGL drivers seem to give a damn about their own state. Why is it always up to the application to keep track of states so that you don't enable something multiple times that already is enabled? OpenGL is a state based API. Shouldn't it be able to shortcut some calls if the current state makes them obsolete anyway...?
-
And another small release which fixes a bug when mixing opaque and transparent blits in that order. In addition, it increases blitting performance slightly.
-
And another one... ;D This time, it reduces matrix multiplications some more.
-
Egon your great :D
-
New version with slightly less garbage creation and slightly improved performance for lights. Nothing to get crazy about...
-
Whooooaaaa FANTASTIC! YEEESSSS :)
-
Another version, this time with working mipmapping even on 1.0/1.1 hybrid phones like my Galaxy and the G1. Some things has been added to support this:
- There's a setting in Config called internalMipmapCreation, which defaults to false. That means that AE will try to figure out the "best" way to generate the mipmaps. If set to true, AE's own generation code will be used regardless of the GPU's/driver's capabilities.
- There's a new static method in Texture called defaultToMipmapping. If called with true, each subsequent texture created will use mipmapping by default.
-
New version with a very subtle change that improves state sorting in some cases.
-
Uploaded a new version that puts the compile()-methods back in to ease porting from desktop jPCT. There's no need to call them directly in AE except when you want to use the same code with desktop jPCT.
In addition, performance of rendering my small objects (like particles) has been improved a little.
-
New version that fixes a bug in VBO-support for objects using floating point coordinates (which isn't the default).
-
Update that improves performance of objects using floating point coordinates. They are coming close to those using fixed point (which is default) now.
-
JavaDOC has been updated as well...
-
Uploaded a new version with some improvements concerning memory management.
-
And another version with reduced memory footprint (0-1MB depending on the scene).
-
I've uploaded another version, but this time it's pretty experimental, which is why it doesn't replace the former one. Instead, it can be found here: http://www.jpct.net/jpct-ae/download/alpha/exp/jpct_ae.jar (http://www.jpct.net/jpct-ae/download/alpha/exp/jpct_ae.jar)
Textures with alpha channels should now use less memory and i've added an option to compress textures. This affects the in-memory copy only, not the data in the gpu. You can either compress single textures or all textures in the TextureManager. The methods in both are simply named compress(). In addition, i've changed the default setting of Config.glAvoidTextureCopies to false.
If you are giving this one a try, please let me know if any problems arise.
-
cool ;D now even without Texture.enable4bpp(true) i can go home and return back.
but there is a problem with colors. green is ok but blue seems pink.
-
(http://img213.imageshack.us/img213/3227/nextbutton.png)
this looks like
(http://img839.imageshack.us/img839/9032/pink1.png)
and
(http://img547.imageshack.us/img547/723/jumppad.png)
looks like
(http://img132.imageshack.us/img132/6056/pink2f.png)
-
Yes, i've screwed up 32 bit mode...i've updated the jar, please give the new version a try.
-
yeap, it's working ok now, thanks ;D
just for curiosity, how do you compress the texture data?
-
yeap, it's working ok now, thanks ;D
just for curiosity, how do you compress the texture data?
The magic of zip... ;D
-
The magic of zip...
So you did my suggestion? :)
Will these changes be added into the desktop version?
-
The magic of zip...
So you did my suggestion? :)
Will these changes be added into the desktop version?
Did i? What was that suggestion again?
-
To compress non used textures in memory (If set)?
-
To compress non used textures in memory (If set)?
Sorry, can't remember that...i guess, i'm just getting old. Well, i don't really see a large point for the desktop version. On the desktop, you actually need the stored texture data much less than on Android with it's sucky Activity management. So you usually can get away with simply setting the option to store them to false....that's unless you are using the software renderer, but that one would need them anyway. So the only benefit would be to compress texture data that the software renderer doesn't need right now. But that would be a complete different logic than what AE does now and requires some kind of texture management component, that currently just isn't there.
In conclusion: Can you show me a situation where this is actually needed on the desktop? If so, i might reconsider adding it.
-
BTW: The exp-Version has been updated with a fix for spherical collision detection.
-
Removed the experimental version and merged the changes into the normal one. Uploaded a new jar of the normal version that includes some minor fixes and optimizations.
-
New version and new javaDocs. rotateAxis() avoids object creation now.
-
Can you upload java doc in zip, please? Thanks :)
-
NP: http://www.jpct.net/jpct-ae/download/alpha/doc.zip (http://www.jpct.net/jpct-ae/download/alpha/doc.zip)
-
NP: http://www.jpct.net/jpct-ae/download/alpha/doc.zip (http://www.jpct.net/jpct-ae/download/alpha/doc.zip)
Thank you :)
-
I decided to leave alpha state, skip beta and release the first official version, 1.22. You can get it here: http://www.jpct.net/jpct-ae/ (http://www.jpct.net/jpct-ae/)
It includes the jPCT-AE jar, the javaDOC and the HelloWorld-example from the wiki (slightly reworked) as an Eclipse project.
Have fun!
-
Fantastic work!
Our project wouldn't be possible without this :)
-
Thanks, gonna try it out.
I'm using rotateAxis() si I'm interested in not having bugs in it :)
-
Uploaded a new jar of the latest build (http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar (http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar)). It includes a detection of triangle strips and if it detects that an object can be rendered as a triangle strip, it will do so. Rumors are that this is faster on Android. I can't verify it, because on my phone everything is slow... >:(
-
Rumors are that this is faster on Android.
Update the Benchmark app and I'll give it a try.
-
That wouldn't help, because no object in the benchmark app can be rendered using triangle strips.... ;)
-
Ah :)
-
Can you add methods setPosition and getPosition fot Object3D?
-
No. getPosition() is what getTranslation() or getTransformedCenter() do, setPosition() would be either translate(...) or clearTranslation();translate(...). No need to add additional methods that do the same thing.
-
Uploaded a new build (http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar (http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar)) that fixes a problem with disposing resources as well as two problems with vertex alpha.
-
No. getPosition() is what getTranslation() or getTransformedCenter() do, setPosition() would be either translate(...) or clearTranslation();translate(...). No need to add additional methods that do the same thing.
For example, if I want to set position of object3D same as light, I must do this everytime:
SimpleVector lv = new SimpleVector(sun.getPosition());
sun.rotate(new SimpleVector(0, 0.05f, 0), plane.getTransformedCenter());
SimpleVector nlv = new SimpleVector(sun.getPosition());
light.translate(nlv.calcSub(lv));
-
No, you can do this as well:
SimpleVector lv = new SimpleVector(sun.getPosition());
sun.rotate(new SimpleVector(0, 0.05f, 0), plane.getTransformedCenter());
light.clearTranslation();
light.translate(sun.getPosition());
If you really want to have a setPosition() for light, just extend Object3D and add it using the same two lines of code.
-
oh, thanks :) ... I dont know, why I must do everything complicated :D
-
Uploaded a new build (http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar (http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar)) that adds the LensFlare class from jPCT, fixes a problem with indexed geometry and VBOs as well as two minor fixes that i forgot about...
-
please... can you add method for add child Light to Object3D? something like this: Object3D.addChild(Light);
-
I would rather not add this. If you have to synchronize their positions, just extend Object3D and let your code do the job.
-
bones definetely need a JIT ::)
The JIT on the crappy Galaxy increases Bones' framerate in this test by ~30%. That's actually more than i expected...
-
right, today i've accidentally upgraded my Nexus One to 2.2.2. bones demo runs at 20fps with 8 animated characters. it was around ~10fps if i remember correctly.
-
how can one accidentally upgrade their phone ? lol
nice to see the improvement though :)
-
I was sleepy and hit the upgrade button thinking it was snooze button ;D
-
Another update. This version improves performance for some collision detection methods and should fix render targets on phones where they didn't work before (like mine): http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar (http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar)
-
I have still problem with render to texture... when I just clear fb, texture is black, but if I whatever try blit, texture is not visible in rendered frame
-
Are you sure that you are using it correctly? Can you post some code snippet?
-
is it correct?
private Texture tex = new Texture(512, 256);
...
fb.setRenderTarget(tex);
fb.clear();
blitText("hello", 5, 5);
fb.removeRenderTarget();
fb.clear();
...
fb.blit(tex, 0, 0, 0, 0, 512, 256, false);
-
I never used this, but to me this would be logical:
In your initialization:
private Texture tex = new Texture(512, 256);
fb.setRenderTarget(tex);
Render loop:
fb.clear();
blitText("hello", 5, 5);
fb.update();
buffer.displayGLOnly(); // optional? i only use gl.. not sure if this is required for software render.
your function
fb.blit(tex, 0, 0, 0, 0, 512, 256, false);
-
As Kaiidyn mentions, you have to do a complete render cycle, i.e. with renderScene, draw, display. A simple blit isn't sufficient. It might work to use display only if all you do is blitting into the render target, but i'm not 100% sure about this. If it doesn't work, just use a dummy world.
-
I use code without renderScene and draw in another case and it is working... so now I add fb.display() (also tried renderScene and draw), same result with texture, but it look like every rendered frame is in lower resolution...
fb.setRenderTarget(tex);
fb.clear();
textureBlitter();
fb.display();
fb.removeRenderTarget();
fb.clear();
-
I think you should not set and remove the renderTarget in every frame, set it in your initialization.. then put the clear, blitter and display in your loop, also remove the 2nd clear, as there is no point in doing it twice (except for making your render slower)
-
No, you have to add and remove it in every frame or otherwise, you'll render everything into the texture and nothing on screen. Maybe it helps if i clarify a little what this actually does (at least in the Android implementation, because it lacks fbo support):
When setting a render target, the view port is limited to the texture size. Then you render your scene as usual. After calling display, the rendered image is copied from the frame buffer into the render target texture. If you remove the render target, the viewport is reset to match the frame buffer's size.
@Thomas: I don't get that "lower resolution" description...do you have a screen shot?
-
In my app I use this test code... Can anybody provide some part of code, that render to texture working?
if (first) {
Thread lb = new GameLoader();
lb.start();
fb.setRenderTarget(tex);
fb.clear();
textureBlitter();
fb.display();
fb.removeRenderTarget();
fb.clear();
}
showLoading(loaded);
fb.display();
first = false;
and here is screen ... after I call renderScene and draw it, "resolution" is correct
(http://imageupload.org/?di=112979415437)
-
Might be related to this: http://www.jpct.net/forum2/index.php/topic,1592.0.html (http://www.jpct.net/forum2/index.php/topic,1592.0.html)?
-
this happens when I blit something or render world... is there any solution?
-
Have you tried to add a clear like i've mentioned in the linked thread? If not, please provide a test case as i don't fully understand what you are doing there.
-
Example that works in the emulator and on my phone:
package com.threed.jpct.example;
import java.lang.reflect.Field;
import javax.microedition.khronos.egl.EGL10;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.egl.EGLDisplay;
import javax.microedition.khronos.opengles.GL10;
import android.app.Activity;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
import android.view.MotionEvent;
import com.threed.jpct.Camera;
import com.threed.jpct.FrameBuffer;
import com.threed.jpct.Logger;
import com.threed.jpct.Object3D;
import com.threed.jpct.Primitives;
import com.threed.jpct.RGBColor;
import com.threed.jpct.Texture;
import com.threed.jpct.TextureManager;
import com.threed.jpct.World;
import com.threed.jpct.util.BitmapHelper;
import com.threed.jpct.util.MemoryHelper;
/**
* @author EgonOlsen
*
*/
public class HelloWorld extends Activity {
private static HelloWorld 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 Texture renderTarget = null;
private int fps = 0;
private int cnt = 0;
protected void onCreate(Bundle savedInstanceState) {
Logger.log("onCreate");
if (master != null) {
copy(master);
}
super.onCreate(savedInstanceState);
mGLView = new GLSurfaceView(getApplication());
mGLView.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {
public EGLConfig chooseConfig(EGL10 egl, EGLDisplay display) {
int[] attributes = new int[] { EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_NONE };
EGLConfig[] configs = new EGLConfig[1];
int[] result = new int[1];
egl.eglChooseConfig(display, attributes, configs, 1, result);
return configs[0];
}
});
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(gl, 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.setAdditionalColor(RGBColor.WHITE);
cube1.setAdditionalColor(RGBColor.BLUE);
cube2.setAdditionalColor(RGBColor.GREEN);
cube3.setAdditionalColor(RGBColor.RED);
cube0.addParent(dummy);
cube1.addParent(dummy);
cube2.addParent(dummy);
cube3.addParent(dummy);
Camera cam = world.getCamera();
cam.moveCamera(Camera.CAMERA_MOVEOUT, 100);
renderTarget = new Texture(256, 256, RGBColor.RED);
MemoryHelper.compact();
if (master == null) {
Logger.log("Saving master Activity!");
master = HelloWorld.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;
}
cnt++;
fb.setRenderTarget(renderTarget);
fb.clear(RGBColor.BLUE);
world.renderScene(fb);
world.draw(fb);
fb.display();
fb.removeRenderTarget();
fb.clear(back);
world.renderScene(fb);
world.draw(fb);
fb.blit(renderTarget, 0, 0, 0, 0, 256, 256, false);
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);
}
}
}
}
-
Another version that does an initial blit into the texture:
package com.threed.jpct.example;
import java.lang.reflect.Field;
import javax.microedition.khronos.egl.EGL10;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.egl.EGLDisplay;
import javax.microedition.khronos.opengles.GL10;
import android.app.Activity;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
import android.view.MotionEvent;
import com.threed.jpct.Camera;
import com.threed.jpct.FrameBuffer;
import com.threed.jpct.Logger;
import com.threed.jpct.Object3D;
import com.threed.jpct.Primitives;
import com.threed.jpct.RGBColor;
import com.threed.jpct.Texture;
import com.threed.jpct.TextureManager;
import com.threed.jpct.World;
import com.threed.jpct.util.BitmapHelper;
import com.threed.jpct.util.MemoryHelper;
/**
* @author EgonOlsen
*
*/
public class HelloWorld extends Activity {
private static HelloWorld 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 Texture renderTarget = null;
private int fps = 0;
private int cnt = 0;
private boolean firstRun = true;
protected void onCreate(Bundle savedInstanceState) {
Logger.log("onCreate");
if (master != null) {
copy(master);
}
super.onCreate(savedInstanceState);
mGLView = new GLSurfaceView(getApplication());
mGLView.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {
public EGLConfig chooseConfig(EGL10 egl, EGLDisplay display) {
int[] attributes = new int[] { EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_NONE };
EGLConfig[] configs = new EGLConfig[1];
int[] result = new int[1];
egl.eglChooseConfig(display, attributes, configs, 1, result);
return configs[0];
}
});
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(gl, 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.setAdditionalColor(RGBColor.WHITE);
cube1.setAdditionalColor(RGBColor.BLUE);
cube2.setAdditionalColor(RGBColor.GREEN);
cube3.setAdditionalColor(RGBColor.RED);
cube0.addParent(dummy);
cube1.addParent(dummy);
cube2.addParent(dummy);
cube3.addParent(dummy);
Camera cam = world.getCamera();
cam.moveCamera(Camera.CAMERA_MOVEOUT, 100);
renderTarget = new Texture(256, 256, RGBColor.RED);
MemoryHelper.compact();
if (master == null) {
Logger.log("Saving master Activity!");
master = HelloWorld.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;
}
cnt++;
if (firstRun) {
fb.setRenderTarget(renderTarget);
fb.clear(RGBColor.BLUE);
Texture t = TextureManager.getInstance().getTexture("texture");
for (int i = 0; i < fb.getWidth(); i += 10) {
fb.blit(t, 0, 0, i, i, t.getWidth(), t.getHeight(), false);
}
fb.display();
fb.removeRenderTarget();
firstRun = false;
}
fb.clear(back);
world.renderScene(fb);
world.draw(fb);
fb.blit(renderTarget, 0, 0, 0, 0, 256, 256, false);
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);
}
}
}
}
If you want to use render to texture as a blit container, you'll run into the problem that the result is displayed upside-down. That's caused by the way OpenGL maps frame buffer to texture coordinates. For blitting, it's a better idea to compose the texture on the bitmap level anyway, The results will look cleaner because they are unaffected by gpu filtering and potential dithering and its more compatible.
-
sorry, problem is on my side... I wrote new test app, too, and it work, so I will have to look where I have bug in my game... and is normal, that texture is flipped around x axis?
PS: ok :)
-
... and is normal, that texture is flipped around x axis?
Yes. As said above, it's caused by the way how OpenGL maps the frame buffer to the texture.
-
I tried the new version of jPCT you released using the two examples you posted.
My phone is having a problem with the render targets as well.
I have a Samsung Galaxy S (model: SAMSUNG-SGH-I897) with Android 2.1.
GL Info from LogCat
02-17 16:29:09.463: INFO/jPCT-AE(27067): OpenGL vendor: Imagination Technologies
02-17 16:29:09.463: INFO/jPCT-AE(27067): OpenGL renderer: PowerVR SGX 540
02-17 16:29:09.463: INFO/jPCT-AE(27067): OpenGL version: OpenGL ES-CM 1.1
Here are some screen shots of the first example code you posted, one from the emulator and one from my phone.
(http://members.cox.net/polomease/test1em.png)
(http://members.cox.net/polomease/test1ph.png)
Here are some screen shots of the second example code you posted, one from the emulator and one from my phone.
(http://members.cox.net/polomease/test2em.png)
(http://members.cox.net/polomease/test2ph.png)
-
Which version of jPCT-AE is that? The latest that i've posted in this thread?
-
]Yes. As said above, it's caused by the way how OpenGL maps the frame buffer to the texture.
BTW: You can flip a blit by doing something like
fb.blit(renderTarget, 0, 0, 0, 256, 256, 256, 256, -256, -1, false, null);
instead of
fb.blit(renderTarget, 0, 0, 0, 0, 256, 256, 256, 256, -1, false, null);
It's not an official feature but it works due to the way blitting is implemented.
-
Which version of jPCT-AE is that? The latest that i've posted in this thread?
Yes, I just downloaded from the link again to make sure I was using the correct one and the problem is still there.
I got the link from this post:
Another update. This version improves performance for some collision detection methods and should fix render targets on phones where they didn't work before (like mine): http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar (http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar)
-
]Yes. As said above, it's caused by the way how OpenGL maps the frame buffer to the texture.
BTW: You can flip a blit by doing something like
fb.blit(renderTarget, 0, 0, 0, 256, 256, 256, 256, -256, -1, false, null);
instead of
fb.blit(renderTarget, 0, 0, 0, 0, 256, 256, 256, 256, -1, false, null);
It's not an official feature but it works due to the way blitting is implemented.
Thanks :)
-
Yes, I just downloaded from the link again to make sure I was using the correct one and the problem is still there.
Should be the latest version then. You can try to set Config.renderTargetsAsSubImages=false; but i don't expect much from that.
-
I have a Samsung Galaxy S (model: SAMSUNG-SGH-I897) with Android 2.1.
I have galaxy s, too ... but with 2.2.1 and texture is correct
-
Most likely a driver issue then...or Polomease's version isn't the latest by accident.
-
I got it to work correctly.
First I set the Config setting you suggested.
Config.renderTargetsAsSubImages = false;
That got the rendering of the texture correct but the rendered texture was flipped.
I then used the code you provided for flipping the texture.
fb.blit(renderTarget, 0, 0, 0, 256, 256, 256, 256, -256, -1, false, null);
After those changes I got the example code to work like the does in the emulator.
It might be a good idea to add the flipping of textures as a feature to the library.
-
I thought that you were already doing something like the blitting trick...or why is the texture correctly oriented in your emulator screen shot....confusing. Anyway, i suggest to not rely on render to texture for your application. Use it as an optional effect but don't base the application on it. It seems to be poorly implemented in the drivers.
-
It seems to be poorly implemented in the drivers.
I understand what you mean, but it's still a bummer. :(
-
I want to replace texture in HelloWorld example by rendered texture, but after this code are all boxs black... and if I try only fb.clear(RGBColor.red) without fb.blit(...), red are only two boxs and two others are black...
Texture tex = new Texture(64, 64);
fb.setRenderTarget(tex);
fb.clear();
fb.blit(tm.getTexture("texture"), 0, 0, 0, 0, 64, 64, false);
fb.display();
fb.removeRenderTarget();
tm.replaceTexture("texture", tex);
-
The red/black issue comes from your combination of ambient and additional color. Ambient in this example is black (0,0,0). If your texture is red and the object's additional color is blue, the result is still black. Try to increase ambient color. I'm not sure about the other issue. Have to tried if it works with that replaceTexture()-part?
-
I set world.setAmbientLight(255, 255, 255) ... tm.replaceTexture(...) works correctly... ok, I fond where is problem...
this code return every what in set in fb.clear(), after this clear command can be whatever... so if I use fb.clear(RGBColor.RED) texture will be red,...
tex = new Texture(64, 64);
fb.setRenderTarget(tex);
fb.clear();
fb.blit(tm.getTexture("texture2"), 0, 0, 0, 0, 64, 64, false);
fb.display();
fb.removeRenderTarget();
tm.replaceTexture("texture", tex);but this works fine... fb.clear() is not used
tex = new Texture(64, 64);
fb.setRenderTarget(tex);
fb.blit(tm.getTexture("texture2"), 0, 0, 0, 0, 64, 64, false);
fb.display();
fb.removeRenderTarget();
tm.replaceTexture("texture", tex);
-
Very strange. I'll investigate this but most likely not today.
-
No idea if it's related, but lwjgl changed the default glClearColor's alpha in v2.7:
http://lwjgl.org/forum/index.php?topic=3741
-
Not related. This is Android only, it has nothing to do with LWJGL.
@Thomas.: Could you please try what happens if you add clear() back in and do
gl.glFlush();
gl.glFinish();
right before the call to fb.display()?
-
no changes
-
I'll try on my phone today. What does it do in the emulator?
-
Ok, i gave it a try on my phone as well as on the emulator as well as on the desktop. While doing so, i discovered some problems with blitting into a render target especially for the desktop version. I fixed those and changed some parts of the AE version too, so that all version behave the same under all setups.
However, this only affects the size of the actual blitting result. The idea itself that your code is using works fine with or without clear in all setups. And it has to be this way, because a simple clear() (which is just a basic gl command) causing such damage makes no sense...it has to be a driver bug. If the emulator, my phone and two desktop PCs can execute it correctly and your phone can't, it the phone's issue and i don't think that i can do anything about it.
Anyway, while trying to fix blitting into a render target, i got the feeling that it isn't a very smart idea. Absolute coordinates and render targets just don't mix very well. I strongly recommend not to do it and i'll add a sentence to the docs of setRenderTarget() that says so.
-
This example not working on my phone and also on emulator (2.3.3... first start today ;D ) ... please do not say me, that I have anywhere bug :) ... blitted "texture" in renderTarget texture is not visible...
package com.threed.jpct.example;
import java.lang.reflect.Field;
import javax.microedition.khronos.egl.EGL10;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.egl.EGLDisplay;
import javax.microedition.khronos.opengles.GL10;
import android.app.Activity;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
import android.view.MotionEvent;
import com.threed.jpct.Camera;
import com.threed.jpct.FrameBuffer;
import com.threed.jpct.Logger;
import com.threed.jpct.Object3D;
import com.threed.jpct.Primitives;
import com.threed.jpct.RGBColor;
import com.threed.jpct.Texture;
import com.threed.jpct.TextureManager;
import com.threed.jpct.World;
import com.threed.jpct.util.BitmapHelper;
import com.threed.jpct.util.MemoryHelper;
/**
* @author EgonOlsen
*
*/
public class HelloWorld extends Activity {
private static HelloWorld 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 Texture renderTarget = null;
private TextureManager tm = TextureManager.getInstance();
private int fps = 0;
private int cnt = 0;
protected void onCreate(Bundle savedInstanceState) {
Logger.log("onCreate");
if (master != null) {
copy(master);
}
super.onCreate(savedInstanceState);
mGLView = new GLSurfaceView(getApplication());
mGLView.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {
public EGLConfig chooseConfig(EGL10 egl, EGLDisplay display) {
int[] attributes = new int[] { EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_NONE };
EGLConfig[] configs = new EGLConfig[1];
int[] result = new int[1];
egl.eglChooseConfig(display, attributes, configs, 1, result);
return configs[0];
}
});
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(gl, w, h);
if (master == null) {
world = new World();
world.setAmbientLight(255, 255, 255);
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);
Camera cam = world.getCamera();
cam.moveCamera(Camera.CAMERA_MOVEOUT, 100);
renderTarget = new Texture(256, 256, RGBColor.RED);
MemoryHelper.compact();
if (master == null) {
Logger.log("Saving master Activity!");
master = HelloWorld.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;
}
cnt++;
fb.setRenderTarget(renderTarget);
fb.clear(RGBColor.BLUE);
world.renderScene(fb);
world.draw(fb);
fb.blit(tm.getTexture("texture"), 0, 0, 0, 0, 64, 64, false);
fb.display();
fb.removeRenderTarget();
fb.clear(back);
world.renderScene(fb);
world.draw(fb);
fb.blit(renderTarget, 0, 0, 0, 0, 256, 256, false);
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);
}
}
}
}
-
Thanks for the test case. I'll have a look at it...
-
maybe could help, that I have to set destX and Y larger that +- 250 for visible texture...
-
Download the latest beta from the link posted some pages before (i've updated it today) and change your texture rendering code to this:
Config.autoMaintainAspectRatio=false;
fb.setRenderTarget(renderTarget);
fb.clear(RGBColor.BLUE);
fb.blit(tm.getTexture("texture"), 0, 0, 0, 0, 64, 64, fb.getWidth(), fb.getHeight(), -1, false, null);
fb.display();
fb.removeRenderTarget();
Config.autoMaintainAspectRatio=true;
As you can see, blitting into the render target is like blitting into the screen, i.e. if you want to make the blit fill the whole screen, the buffer's dimension have to be used not the texture's dimensions. However, you have to disable the aspect ratio adjustment before or otherwise, the result isn't pleasing.
That said, i can only repeat myself: Don't do this! Don't blit into a render target! The Config-changes before and after are actually a crude way to deal with the fact that absolute screen coordinates and render targets don't mix very well.
-
texture is visible now :) I think, that it is interesting feature and it has good use in my game :) ... but what exactly do autoMaintainAspectRatio? I have same result on true or false...
-
You might have the same result after one iteration but usually not for the first one. It does what the docs state that it does. It's usually not needed to disable it, but for some render to texture stuff, it's better to disable it (or set y-fov explicitly).
-
Could you look on this one? setRenderTarget is still not working...
package com.threed.jpct.example;
import java.lang.reflect.Field;
import javax.microedition.khronos.egl.EGL10;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.egl.EGLDisplay;
import javax.microedition.khronos.opengles.GL10;
import android.app.Activity;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
import android.view.MotionEvent;
import com.threed.jpct.Camera;
import com.threed.jpct.Config;
import com.threed.jpct.FrameBuffer;
import com.threed.jpct.Logger;
import com.threed.jpct.Object3D;
import com.threed.jpct.Primitives;
import com.threed.jpct.RGBColor;
import com.threed.jpct.Texture;
import com.threed.jpct.TextureManager;
import com.threed.jpct.World;
import com.threed.jpct.util.BitmapHelper;
import com.threed.jpct.util.MemoryHelper;
/**
* @author EgonOlsen
*
*/
public class HelloWorld extends Activity {
private static HelloWorld 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 Texture renderTarget = null;
private int fps = 0;
private int cnt = 0;
protected void onCreate(Bundle savedInstanceState) {
Logger.log("onCreate");
if (master != null) {
copy(master);
}
super.onCreate(savedInstanceState);
mGLView = new GLSurfaceView(getApplication());
mGLView.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {
public EGLConfig chooseConfig(EGL10 egl, EGLDisplay display) {
int[] attributes = new int[] { EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_NONE };
EGLConfig[] configs = new EGLConfig[1];
int[] result = new int[1];
egl.eglChooseConfig(display, attributes, configs, 1, result);
return configs[0];
}
});
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(gl, 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.setAdditionalColor(RGBColor.WHITE);
cube1.setAdditionalColor(RGBColor.BLUE);
cube2.setAdditionalColor(RGBColor.GREEN);
cube3.setAdditionalColor(RGBColor.RED);
cube0.addParent(dummy);
cube1.addParent(dummy);
cube2.addParent(dummy);
cube3.addParent(dummy);
Camera cam = world.getCamera();
cam.moveCamera(Camera.CAMERA_MOVEOUT, 100);
renderTarget = new Texture(256, 256, RGBColor.RED);
MemoryHelper.compact();
if (master == null) {
Logger.log("Saving master Activity!");
master = HelloWorld.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;
}
cnt++;
Config.autoMaintainAspectRatio = false;
fb.setRenderTarget(renderTarget);
fb.clear(RGBColor.BLUE);
world.renderScene(fb);
world.draw(fb);
fb.display();
fb.removeRenderTarget();
TextureManager.getInstance().replaceTexture("texture", renderTarget);
Config.autoMaintainAspectRatio = true;
fb.clear(back);
world.renderScene(fb);
world.draw(fb);
fb.blit(renderTarget, 0, 0, 0, 0, 256, 256, false);
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);
}
}
}
}
-
Works fine for me (except for the fact that it looks awful because of the setup of the scene, but that's another thing). What's the exact problem?
-
screen:
(http://2i.cz/2i/t/96bbc1eb38.jpg) (http://2i.cz/96bbc1eb38)
-
Have you tried to set this at the start of the app:
Config.renderTargetsAsSubImages = false;
?
-
new screen:
(http://2i.cz/2i/t/b578c1eb38.jpg) (http://2i.cz/b578c1eb38)
-
I tried it also on emulator and there is same result as on my phone... could you do something with it, please :)
-
What's the problem with that image? You get exactly what you asked for in your code. The rendering is ugly but correct IMHO.
-
Is it correct?
package com.threed.jpct.example;
import java.lang.reflect.Field;
import javax.microedition.khronos.egl.EGL10;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.egl.EGLDisplay;
import javax.microedition.khronos.opengles.GL10;
import android.app.Activity;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
import android.view.MotionEvent;
import com.threed.jpct.Camera;
import com.threed.jpct.Config;
import com.threed.jpct.FrameBuffer;
import com.threed.jpct.Logger;
import com.threed.jpct.Object3D;
import com.threed.jpct.Primitives;
import com.threed.jpct.RGBColor;
import com.threed.jpct.Texture;
import com.threed.jpct.TextureManager;
import com.threed.jpct.World;
import com.threed.jpct.util.BitmapHelper;
import com.threed.jpct.util.MemoryHelper;
/**
* @author EgonOlsen
*
*/
public class HelloWorld extends Activity {
private static HelloWorld 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 Texture renderTarget = null;
private int fps = 0;
private int cnt = 0;
protected void onCreate(Bundle savedInstanceState) {
Logger.log("onCreate");
if (master != null) {
copy(master);
}
super.onCreate(savedInstanceState);
mGLView = new GLSurfaceView(getApplication());
mGLView.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {
public EGLConfig chooseConfig(EGL10 egl, EGLDisplay display) {
int[] attributes = new int[] { EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_NONE };
EGLConfig[] configs = new EGLConfig[1];
int[] result = new int[1];
egl.eglChooseConfig(display, attributes, configs, 1, result);
return configs[0];
}
});
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() {
Config.renderTargetsAsSubImages = false;
}
public void stop() {
stop = true;
}
public void onSurfaceChanged(GL10 gl, int w, int h) {
if (fb != null) {
fb.dispose();
}
fb = new FrameBuffer(gl, w, h);
if (master == null) {
world = new World();
world.setAmbientLight(255, 255, 255);
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);
Camera cam = world.getCamera();
cam.moveCamera(Camera.CAMERA_MOVEOUT, 100);
renderTarget = new Texture(256, 256, RGBColor.RED);
MemoryHelper.compact();
if (master == null) {
Logger.log("Saving master Activity!");
master = HelloWorld.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;
}
cnt++;
Config.autoMaintainAspectRatio = false;
fb.setRenderTarget(renderTarget);
fb.clear();
/*world.renderScene(fb);
world.draw(fb);
fb.display();*/
fb.blit(TextureManager.getInstance().getTexture("texture"), 0, 0, 0, 0, 64, 64, false);
fb.removeRenderTarget();
TextureManager.getInstance().replaceTexture("texture", renderTarget);
Config.autoMaintainAspectRatio = true;
fb.clear(back);
world.renderScene(fb);
world.draw(fb);
fb.blit(renderTarget, 0, 0, 0, 0, 256, 256, false);
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);
}
}
}
}
(http://2i.cz/2i/t/b43c85af7c.jpg) (http://2i.cz/b43c85af7c)
-
The code seems to be correct, but the result should actually be a black texture, not a red one. Drivers ARE flaky with coyping data back from the frame buffer. If it doesn't work on your phone with neither setting, then it just doesn't work. There's no magic that i can apply to make it work. I can only repeat myself: Don't rely on it for your application. Make it an option for devices that can handle it, but don't base the app on it.
That said, what exactly do you want to use this feature for?
-
Last screen is from emulator... I have elevator in my game and I want control it by panel in game, so I need render floor names and position of elevator to texture
-
You don't need render to texture for that. You can either create a texture containing all these floor-names and stuff in different parts of it and just switch the u/v-coordinates...that might be the fastest solution. Or you can prerender those textures and just switch them on demand (that's what i would do). Or you can use an ITextureEffect to fiddle around with the texture on the pixel level to update it or you can render fonts into a Bitmap using standard Android methods and create a new texture from that each time. Using render to texture for this is the worst possible and most flaky solution IMHO...and i repeat myself again: Don't do it! It's flaky! No idea why the emulator is red in this screen shot (what emulator is that? Mine looks totally different but then again, i'm not using 2.3). Might be that your test case's code isn't correct and i haven't seen it. Fact is, that the code (actually it's one line with a gl call...you can't do much about it if it doesn't work) and my test cases work fine in the desktop version, on my phone, on other people's phones and in all the emulator versions that i've tried. Why it doesn't work for you...no idea. But i think that i've done all that i could to make it work as good as possible. For me, there's nothing left to do here.
-
Have you any example of texture coordinates and sets more layers of textures? I set this just in 3D max, I never saw, how it looking in code
-
Not layers. Just multiple images in one texture. I think i'm using this in Robombs to animate the explosion billboards. However, using multiple regenerated textures might be the simpler solution unless you your elevator has dozens of floors.
-
A new version with a small fix for the OBJ-loader: http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar (http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar)
-
New version with more gc friendly behaviour of ellipsoid collision detection. A bug prevented a former optimization from kicking in, so that too many matrices got created: http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar (http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar)
-
New version with reduces object creations when calling calcMinDistance directly on Object3Ds. Get it here: http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar (http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar)
-
That just made my day :) Thanks!
-
As you all know...well, maybe not but anyway...jPCT-AE has support for libgdx (http://code.google.com/p/libgdx/ (http://code.google.com/p/libgdx/)) since a few releases. You can drop in the libs and the native parts as described on the libgdx page and jPCT-AE will auto-detect it and use it for some stuff. The main purpose is to increase buffer upload speeds for animated objects. My old Samsung Galaxy was too slow to show any benefit of this, so i tried it again with my new Nexus S. I ran An3DBenchXL which has a test that pretty much depends on buffer uploads: "Ninjas' garden"...the results, at least with Gingerbread, were disappointing: Framerate increased from 16.08fps using jPCT-AE's optimized buffer uploads to 17.37fps when using libgdx for this. While this is nice to have, i really expected more. I guess Google has improved the buffer uploads to a degree where it just doesn't matter anymore. It might be a different story with 2.1 or 2.2 though...
-
You have nexus S?? :) it is nice message, so we will look forward to OGL 2 support :)
-
I've already looked into it...it's a real pain to add support for it, because they scrapped so many things in 2.0. Plus i have to write a monster shader to mimic everything that the fixed function pipeline does...it'll take some time...
-
What about the new version, any new info? :)
-
No, i'm not working on that ATM...as said, it'll take some time.
-
New version that fixes a problem when mixing lit and unlit objects: http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar (http://www.jpct.net/jpct-ae/download/alpha/jpct_ae.jar)
Please note that this version also includes pre-alpha support for GLES2.0. Please don't use it. It's not stable yet and i don't support it right now.
-
Official releases of 1.23 are out for the desktop version as well as for AE: http://www.jpct.net/forum2/index.php/topic,2089.0.html (http://www.jpct.net/forum2/index.php/topic,2089.0.html)
Have fun!
-
Could you fix render to texture (if is possible)? I think that it will be the fastest way in the solution to my problem...
-
Could you fix render to texture (if is possible)? I think that it will be the fastest way in the solution to my problem...
There's nothing to be fixed, i'm afraid. If it doesn't work, then it's a driver issue. I can't work around this...
-
First alpha version with support for OpenGL ES 2.0 is out: http://www.jpct.de/download/net/jpct-ae_124_alpha.zip (http://www.jpct.de/download/net/jpct-ae_124_alpha.zip)
-
I think what documentaion from privious version, because, i can't find for example GLSLShader class in javadoc.
-
No, it's current. But i might have forgotten to add GLSLShader to it. I'll fix this when i'm back home
-
Documentation is fixed now. Please download it again.
-
I have problem with fb.blit(...) in ogl 2. Same code, before without any problem, but now, without any warning or crash, nothing is blitted in the screen
onSurfaceChanged(...){
fb = new FrameBuffer(w,h);
blitter = new Blitter(fb); // class where is blitted GUI
}
onDrawFrame(...){
blitter.blitAimCross(...);
}
-
I can't reproduce this. Does the HelloShader-example work fine?
-
yes
-
Ok...can you create a minimal test case to reproduce this problem?
-
I found issue, when I did the example, if you set "Config.farPlane = 2000;" fb.blit(...) transparency does not work... additional color does not work... is disabled black color as transparent?
edit: sorry, black working, but problem is probably in OPAQUE_BLITTING
image:
(http://2i.cz/2i/t/9c762f05d6.jpg) (http://2i.cz/9c762f05d6)
ogl 1.1:
(http://2i.cz/2i/t/6298c1eb38.jpg) (http://2i.cz/6298c1eb38)
ogl 2.0:
(http://2i.cz/2i/t/40bae3c91a.jpg) (http://2i.cz/40bae3c91a)
-
The blitting issue should be fixed (some weird accuracy issue with the projection matrix that i last spotted on a GeForce 2MX a decade ago...). Please re-download the zip. I can't verify that problem with additional color (assuming that you are talking about the addColor in blit())...it seems to work fine for me. I'll have a look at that black-color-opaque-blitting-whatever-issue now...
-
I don't get this OPAQUE_BLITTING-thing...what is the code that produces the output in your screen shots!? Neither of them looks opaque. Is the png-file that you've uploaded the actual texture? Or does the real one contain an alpha channel?
-
I am looking for what is wrong, because when I did simple test, additional color is working...
this is code of screens (uploaded image is actual texture):
fb.blit(pad, 0, 0, x, y, 128, 128, 128, 128, 50, FrameBuffer.OPAQUE_BLITTING, addColor);
-
If that is the code that blits it, i would say that neither screen shot is correct because neither texture is blitted opaque. Are you clearing the frame buffer with additional alpha or something?
-
I can not find where is problem in addColor... just fb.claer();
-
Sorry, i need some test case to get the problem with opaque/non-opaque/whatever stuff...
-
I tried set to transValue whatever and it is without any effect, so maybe this is issue :)
-
It works fine when using additive blending (which my test cases did) but seems to fail when additive is set to false...i'll look at it.
-
Should be fixed now...please re-download the zip and try again.
-
addColor and transparency work now, thanks :)
-
Became a miracle and render to texture works (maybe newer firmware?...). But why boxes rendered more times? and fb.blit(...) does not works when is rendered and drawed world, without works, but in bad dimensions. I used "Config.autoMaintainAspectRatio = false" and "Config.renderTargetsAsSubImages = false"
(http://2i.cz/2i/t/d1bae3c91a.jpg) (http://2i.cz/d1bae3c91a)
-
No idea. Maybe you are seeing the last render result blitted into the new one there? Maybe it doesn't work correctly even if it looks like it at first glance...just don't use this feature! It's too flaky and doesn't work on all devices (as you've already noticed multiple times). So....DON'T DO IT! And about blitting into the render target, the docs for setRenderTarget(..) state: "While possible, it's not recommended to blit into a render target."...just follow that advice.
-
New alpha here: http://www.jpct.de/download/net/jpct-ae_124_alpha.zip (http://www.jpct.de/download/net/jpct-ae_124_alpha.zip)
This one adds: Option to enable AA via an AAConfigChooser in util as well as two fixes concerning sharing compiled data for animated objects.
-
i don't arrive to launch the application "helloshader" on the emulator pc
-
emulator does not support ogl 2.0
-
how could i do to see the helloshader so? because i don't have a tablet
-
You don't need a tablet, but a real phone would help. If that isn't available, you can see a video on Youtube: http://www.youtube.com/watch?v=5Zgn1OCDIus (http://www.youtube.com/watch?v=5Zgn1OCDIus)
-
Tried steep parallax mapping today...it's not feasible on current mobile gpus. Performance was around 4 fps on my Nexus S. Just too many ifs and whiles in the fragment shader, i guess... :(
-
Hey EgonOlsen, have you been able to test JPCT-AE against any of the tablet-based devices? If so, have you notice any performance difference/change?
-
No, i haven't tested it on a tablet yet. Judging from the benchmark results, performance is fine. It might be bit lower due to the higher resolution though. Here's for example a result from some Galaxy Tab: http://www.jpct.de/an3dbenchxl/details.php?code=MTY0MjUx108470 (http://www.jpct.de/an3dbenchxl/details.php?code=MTY0MjUx108470)
-
The resolution for these devices are only going to get higher over time (not to mention CPU and RAM). This is just one of the first links that came back from comparing the Galaxy Tab series models:
http://socialcompare.com/en/comparison/samsung-galaxy-tab-10-1-vs-8-9-vs-7-inch (http://socialcompare.com/en/comparison/samsung-galaxy-tab-10-1-vs-8-9-vs-7-inch)
I'd love to see these features your working on run against the larger devices as well.
-
Yes, i tested some simple applications based on JPCT. On smaller Galaxy Tab in visual and perfomance case i did't see any differences between Galaxy Tab and HTC Desire S.
-
I'm not sure what your question is all about...the engine doesn't care about the device it's running on as long as it's Android... ???
-
I was simply referring to your new feature/enhancement tests. What I was hoping to suggest (sorry if I was not clear) was for you to consider higher performance Android devices as well (such as Galaxy Tab 10.1, Xoom and Google TV) again if at all possible.
Perhaps parallax mapping (and other features your working on) may not be ready for the current line of smartphones but it may run well on tablets. Anyhow, it was just a suggestion and I would be more than happy to help test new features for you if interested.
Thanks again for your hard work to make this engine awesome! :)
-
Tried steep parallax mapping today...it's not feasible on current mobile gpus. Performance was around 4 fps on my Nexus S. Just too many ifs and whiles in the fragment shader, i guess... :(
I tried add your parallax shader and object to my game and when camera is moving closer (object take more pixels) fps drop down very fast, from 65 (I have removed default lock on galaxy s) to 25... bump or normal mapping would be faster... how it goes with the fragment lights? :)
-
Perhaps parallax mapping (and other features your working on) may not be ready for the current line of smartphones but it may run well on tablets. Anyhow, it was just a suggestion and I would be more than happy to help test new features for you if interested.
Everybody is free to implement any kind of shaders...that parallax mapping thingy was just a test of mine. It's not part of the engine itself and it maybe never will.
-
I tried add your parallax shader and object to my game and when camera is moving closer (object take more pixels) fps drop down very fast, from 65 (I have removed default lock on galaxy s) to 25... bump or normal mapping would be faster... how it goes with the fragment lights? :)
You can strip the shader down to be simple normal mapping shader...or try these:
uniform mat4 modelViewMatrix;
uniform mat4 modelViewProjectionMatrix;
uniform vec4 additionalColor;
uniform vec4 ambientColor;
uniform vec3 lightPositions[8];
attribute vec4 position;
attribute vec4 tangent;
attribute vec3 normal;
attribute vec2 texture0;
varying vec3 lightVec[2];
varying vec3 eyeVec;
varying vec2 texCoord;
void main(void)
{
texCoord = texture0.xy;
vec3 n = normalize(modelViewMatrix * vec4(normal,0.0)).xyz;
vec3 t = normalize(modelViewMatrix * vec4(tangent.xyz, 0.0)).xyz;
vec3 b = tangent.w*cross(n, t);
vec3 vVertex = vec3(modelViewMatrix * position);
vec3 tmpVec = lightPositions[0].xyz - vVertex;
vec3 lv;
vec3 ev;
lv.x = dot(tmpVec, t);
lv.y = dot(tmpVec, b);
lv.z = dot(tmpVec, n);
lightVec[0]=lv;
tmpVec = vVertex*-1.0;
eyeVec.x = dot(tmpVec, t);
eyeVec.y = dot(tmpVec, b);
eyeVec.z = dot(tmpVec, n);
gl_Position = modelViewProjectionMatrix * position;
}
precision mediump float;
varying vec3 lightVec[2];
varying vec3 eyeVec;
varying vec2 texCoord;
uniform sampler2D textureUnit0;
uniform sampler2D textureUnit1;
uniform vec3 diffuseColors[8];
uniform vec3 specularColors[8];
uniform vec4 ambientColor;
uniform float invRadius;
void main ()
{
vec4 vAmbient = ambientColor;
vec3 vVec = normalize(eyeVec);
vec4 base = texture2D(textureUnit0, texCoord);
vec3 bump = normalize(texture2D(textureUnit1, texCoord).xyz * 2.0 - 1.0);
float distSqr = dot(lightVec[0], lightVec[0]);
float att = clamp(1.0 - invRadius * sqrt(distSqr), 0.0, 1.0);
vec3 lVec = lightVec[0] * inversesqrt(distSqr);
float diffuse = max(dot(lVec, bump), 0.0);
vec4 vDiffuse = vec4(diffuseColors[0],0) * diffuse;
float specular = pow(clamp(dot(reflect(-lVec, bump), vVec), 0.0, 1.0), 0.85);
vec4 vSpecular = vec4(specularColors[0],0) * specular;
vec4 col = (vDiffuse*base + vSpecular) * att;
gl_FragColor = col+(vAmbient*base + vDiffuse*base + vSpecular) * att;
}
What do you mean with "how it goes with the fragment lights"?
-
Thanks, I look at it tomorrow :) ... Are you working on implementation point and spot light to engine?
-
No, not really. Currently, my strategy is to let people write their own shader code for this, if they want to use it. That way, they can better adopt to the hardware/software they are using. I'm having enough trouble making the default shaders run on all devices (still no test results from Tegra 2...), which is why i don't want to add another layer of stuff that might require support from my side ATM. This may change once this ES 2.0 feature is stable and proven.
-
normal mapping improve just 3 fps :(
-
Yes, offset mapping isn't that much more shader code, so it isn't much slower.
-
No, not really. Currently, my strategy is to let people write their own shader code for this, if they want to use it. That way, they can better adopt to the hardware/software they are using. I'm having enough trouble making the default shaders run on all devices (still no test results from Tegra 2...), which is why i don't want to add another layer of stuff that might require support from my side ATM. This may change once this ES 2.0 feature is stable and proven.
Hey, I can test it on Tegra 2 tablet!
-
Cool...here you go: http://www.jpct.net/download/tmp/An3DBenchXL.apk (http://www.jpct.net/download/tmp/An3DBenchXL.apk)
If you've installed another version of An3DBenchXL, you might have to uninstall it first. This version offers two render paths...the "normal" 1.1 one and the 2.0 one. If all goes well (what i don't really expect), the 2.0 path should look like the 1.1 path.
-
Here are the An3DBenchXL 1.1 results at 1280x752 on a Tegra2 Tablet (Android 3.1).
OpenGL ES 2.0
DD 33.74
FP 25.60
NG 9.48
ENC 60.96
MI 24.97
Score 26796
OpenGL ES 1.1
DD 26.42
FP 28.31
NG 14.66
ENC 60.90
MI 29.69
Score 27702
All tests looked identical as far as I can tell, except for Magic Island which was missing the Sun and the lens flare in 2.0. The fog may have been thicker as well.
-
Many many thanks for testing. I've encountered that blitting problem with ES2.0 before, but i considered it to be fixed. Obviously, that's only true for PowerVR and Adreno powered devices. I've uploaded a modified version here: http://jpct.de/download/tmp/es20/An3DBenchXL.apk (http://jpct.de/download/tmp/es20/An3DBenchXL.apk) (you might have to uninstall the former one). It is fixed to ES2.0 and runs the terrain test only. If there's still no lens flare effect visible, i have to try something else. Thanks again for testing.
-
Not a problem, glad to help :) I ran that update and it all looks good now, both the sun and flares render like they do in ES1.1.
The edges of the water tear quite a lot in both render paths, looks like a clipping or zbuffer issue. Not sure if that's normal or not. I can grab a screenshot if needed.
-
The zbuffer flaws in this test are pretty common. They are caused by the GPUs being pretty inaccurate, the view distance being pretty high and the zbuffer being 16bit only. I don't worry about them. It's great that the blitting works fine now. It was an accuracy problem in the shader then. Now that it runs on all three major GPU architectures, i think we are coming closer to beta state... ;D
-
Sounds good :)
I gave it a run on an OMAP 4430 (PowerVR SGX540, Android 3.1) with no problems, performance was similar to the Tegra2.
The cloth in ENC looked better on the OMAP, the Tegra displayed tearing/clipping when the cloth touches the ball (both GL11 and GL20). No tearing at all on the OMAP.
DD 36.05
FP: 23.08
NG 13.86
ENC 59.52
MI 31.51
28401 (ES 1.1 scored 30292)
That modified apk with just the terrain test looks fine on the OMAP as well.
-
I consider OpenGL ES2.0 support to be stable enough for a release now (consider this feature to be still in beta though)...so here are the changes:
Added support for OpenGL ES 2.0. Changed default value of Config.useVBO from false to true. Fixed the OBJ-loader to handle files that contain "polygons" that only contain two vertices. Added support for diffuse polygon colors to the DeSerializer.
Fixed behaviour of the TextureManager to match the documentation. Sharing data with objects that have been compiled to floating point data now works fine. Fixed two issues with sharing compiled data for animated objects. Added on option to Config (useRotationPivotFrom3DS) to read
the rotation pivot from a 3DS. Fixed some minor code flaws that FindBugs has found. Fixed a flaw with serialized objects that made already build objects being build again when loading them into jPCT-AE. Added an option to FrameBuffer to override a render target's dimensions for the fov calculations.
Extended the IRenderHook-interface by a setCurrentObject3D()-method. Added a method to Object3D to query for the number of used lights at render time. Fixed a bug that caused the bounding box to be ignored on some cloned and deserialized objects. Fixed occlusion of lens flares in the LensFlare-class.
Get it from the download page: http://www.jpct.net/download.html (http://www.jpct.net/download.html)
Have fun!
-
I haven't tested it but is there a way to test if the device supports OpenGL ES2.0 before using it?
-
Not sure...maybe setting the 2.0 context fails with some exception, if not supported. You should be able to test this in the emulator. jPCT-AE itself can't detect it.
-
Since it's a beta I'll leave it for now. But I'll try once its known to be stable for its anti-aliasing support.
-
It was in beta back in October 2011...but i consider it to be stable now. I'm building my RPG game with OpenGL ES 2.0 and i haven't found a problem related to it for now.
-
Great in that case I'll give a try... hopefully one of our 10 devices around hasn't got opengl 2.0 so I can test the fall back.
-
I must be missing something. I've followed the wiki but this method is missing for me "mGLView.setEGLContextClientVersion(2);"
-
I depends on the Android SDK version you are using. ES 2.0 support has been added with 2.1..2.2....? Something like that...
-
Ah seems it was added in 2.2. I'm targeting 2.1 which is probably the reason.
Blah that is quite annoying then. I was hoping to use it. Maybe could try some reflection, check if the method exists and use it, not use if that would work...
-
With a little fun I finally got it to work. Here is the code if anyone wants to do the same :)
boolean isOpenGl2 = false;
try {
Method setEGLContextClientVersion = GLSurfaceView.class.getMethod(
"setEGLContextClientVersion", int.class );
/* success, this is a newer device */
setEGLContextClientVersion.invoke(mGLView, 2);
mGLView.setEGLConfigChooser(new AAConfigChooser(mGLView));
isOpenGl2 = true;
Log.d("WW", "Using OpenGL 2.0");
} catch (NoSuchMethodException e) {
Log.d("WW", "Fail to find setEGLContextClientVersion, must be an older device.");
} catch (IllegalArgumentException e) {
} catch (IllegalAccessException e) {
} catch (InvocationTargetException e) {
}
if(!isOpenGl2){
Log.d("WW", "Using OpenGL 1.1");
}
However with AA it slowed even my Galaxy Nexus to 17fps, so looks like that is off the table :( Though it looked a lot nicer!
Then it was crashing when I removed the AA line.
03-01 20:32:12.204: D/WW(28677): Using OpenGL 2.0
03-01 20:32:12.266: D/libEGL(28677): loaded /vendor/lib/egl/libEGL_POWERVR_SGX540_120.so
03-01 20:32:12.266: D/libEGL(28677): loaded /vendor/lib/egl/libGLESv1_CM_POWERVR_SGX540_120.so
03-01 20:32:12.266: D/libEGL(28677): loaded /vendor/lib/egl/libGLESv2_POWERVR_SGX540_120.so
03-01 20:32:12.384: D/OpenGLRenderer(28677): Enabling debug mode 0
03-01 20:32:12.407: W/dalvikvm(28677): threadid=11: thread exiting with uncaught exception (group=0x40a721f8)
03-01 20:32:12.407: E/AndroidRuntime(28677): FATAL EXCEPTION: GLThread 1182
03-01 20:32:12.407: E/AndroidRuntime(28677): java.lang.RuntimeException: createContext failed: EGL_BAD_CONFIG
03-01 20:32:12.407: E/AndroidRuntime(28677): at android.opengl.GLSurfaceView$EglHelper.throwEglException(GLSurfaceView.java:1164)
03-01 20:32:12.407: E/AndroidRuntime(28677): at android.opengl.GLSurfaceView$EglHelper.throwEglException(GLSurfaceView.java:1156)
03-01 20:32:12.407: E/AndroidRuntime(28677): at android.opengl.GLSurfaceView$EglHelper.start(GLSurfaceView.java:1003)
03-01 20:32:12.407: E/AndroidRuntime(28677): at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1348)
03-01 20:32:12.407: E/AndroidRuntime(28677): at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1202)
03-01 20:32:12.743: D/OpenGLRenderer(28677): Flushing caches (mode 0)
03-01 20:32:13.009: D/OpenGLRenderer(28677): Flushing caches (mode 1)
03-01 20:32:15.837: I/Process(28677): Sending signal. PID: 28677 SIG: 9
Why would it crash just from removing this line?
mGLView.setEGLConfigChooser(new AAConfigChooser(mGLView));
-
Because of this:
EGL_BAD_CONFIG
. I'm not sure why, but it somehow thinks that your default config is wrong. But that's out of the scope of jPCT-AE. How you create the context is totally up to you. You might want to look at the HelloShader-example and see that runs on this device. If it does, just do what it does in your code.
-
Oh silly me, I didn't realise you didnt need to do
mGLView.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {...That problem is solved :)
With the 400 lines (yes we need to support that many lines) OpenGL 2.0(No AA) is still very slow compared to 1.1. I'm going about 17-22 fps on my Galaxy Nexus. No trouble in 1.1 (smooth 60fps).
However OpenGL 2.0 + AA seems to be smooth also when there is no lines.
Is there any optimisations you can do with OpenGL 2.0 and lines? No big problem if you can't.
-
However with AA it slowed even my Galaxy Nexus to 17fps, so looks like that is off the table :( Though it looked a lot nicer!
But lines without AA in ES 2.0 are fine?
-
But lines without AA in ES 2.0 are fine?
Other than still being just about as slow, yep they were fine.
-
I see...i'm using a custom shader in ES 2.0 mode for rendering the lines and i did the state management in a very naive way to get things working. It should be possible to improve this. I'll create myself a test case this evening and see if i can improve it.
-
It should be possible to improve this. I'll create myself a test case this evening and see if i can improve it.
Awesome stuff.
-
Please re-download the jar. I've updated it with one that should be faster in both modes. The ES 2.0 mode still isn't as fast as the 1.0 mode, but on the Nexus S, it went up from 10fps to 40fps when drawing 501 lines. The performance drop comes from the additional overhead introduced by setting the shader's uniform for each line and sadly can't be reduced.
Now on to transparency...
-
...transparency has been added. The colors alpha value will be taken into account, a new setter for transparency mode is in Polyline. Please download the jar again and let me know if it works/helps.
-
You are awesome. Smooth as butter. I have it now using OpenGL 2.0 on mid range devices and turning AA on for high end.
Now to do some testing on all the devices around here.
Edit: Smooth all around and looks better than the iphone version :)
-
Egon, how it seems with support of post-processing effects? If I'm correct, it's render scene to texture, render plane with texture and fragment shader and display... I want depth of field (another project than I sent to you) :)
edit: In this demo working render to texture without any problem. Zip contains also source code.
http://dl.dropbox.com/u/26148874/render%20to%20texture.zip
-
Version 1.25 has been released!
Change log:
Fixed a bug in the texture matrix support of the OpenGL ES 2.0 renderer. Added the ShaderLocator class to allow for different shader locations. Added a method to SimpleVector to calculate a reflection vector. Added setRotationPivot() to Overlay.
Added the option to use an alpha channel to the AAConfigChooser. Added a method to lock a mesh to Mesh. Added a method to Object3D to share texture data between objects. Fixed a flaw when trying to set non-existent uniforms and attributes in a shader.
Fixed replacement shaders in GLSLShader. Serialized objects can now contain an octree. Object3D.clearRotation() now also resets the scale. Added compile(boolean)-method to Object3D for compatibility with desktop jPCT. Fixed a problem when deserializing objects with diffuse colors. jPCT now automatically detects the default thread, so there's usually no need to set it in World.
Added an additional optimization to ellipsoid collision detection; setting collision detection to optimized now has an affect on ellipsoid collision detection. Added a calcAngleFast()-method to SimpleVector. Optimized compress() in Texture-class. Added a Virtualizer class to support swapping texture data to disk.
Fixed a bug that screwed up textures when sharing meshes of objects that use multiple textures and were stripped. Reduced objects created by collision detection, shader support and fogging support. Fixed context recovering for animated objects. Fixed an inaccuracy in the Overlay when the camera matrix wasn't 100% orthogonal.
Fixed a bug with not correctly managing states when using tangent verctors. Fixed a bug in the visibility detection for objects that consist of only one or two polygons. Fixed setOrientation() on scaled objects. Added the option to override the calculated distance of a light to an object. Fixed fogging when used in multiple worlds in one frame.
Fixed a bug that occured when recovering the from a context change on a floating point VBO. Added basic support for primitive lines with the new Polyline-class. Deprecated Texture.enableGLClamping() and replaced it with Texture.setClamping(<boolean>). Fixed compression ratio calculation for zipped textures. Changed mip mapping default to true.
Changed behaviour of animated objects that share compiled data. Now, the parent object doesn't have to touched to update the animation if a child has been animated. Added getProgram() to GLSLShader. Fixed behaviour of build() when used on models on which calcNormals() has been called before. Added support for setting a maximum number of lights for an Object3D.
Serialized objects now include the name of the object. The rotation pivot will now be deserialized if it's part of the file. Fixed Loader.readTextureNames3DS to actually read texture names. Fixed loading of flawed .mtl-files. General performance improvements.
Some additional info: http://www.jpct.net/forum2/index.php/topic,2791.0.html (http://www.jpct.net/forum2/index.php/topic,2791.0.html)
-
Could you explain a little more detail on the Virtualizer?
-
Could you explain a little more detail on the Virtualizer?
Sure! The engine has to keep texture and mesh data to be able to upload it again onto the gpu in case of an OpenGL context switch. By default, this happens in the VM's memory reducing free memory for the actual application. With the Virtualizer, you can swap this data to disk/card. Just create a Virtualizer, set the current Context and assign it to either the TextureManager or the Object3Ds in questions. For textures, you have to call TextureManager.virtualize(<Texture>); in addition. For Object3Ds, it happens automagically. jPCT-AE will then swap the memory to disk/card and reload it from there if needed.
-
Sounds awesome. Though since I need to keep resume times fast doesn't sound like I can use it.
Isn't also ETC1 texture compression new in this version?
-
Yes. But i forgot to add it to the log, because at the time i implemented it, i wasn't sure if i would keep it.
-
because at the time i implemented it, i wasn't sure if i would keep it.
Why's that?
I noticed it also slows down resuming. Seems like it compresses the images again on resume? I thought it would do it once and only use the ETC1 compressed textures. Unless I'm mistaken?
-
I noticed it also slows down resuming. Seems like it compresses the images again on resume? I thought it would do it once and only use the ETC1 compressed textures. Unless I'm mistaken?
Yes, it compresses them on each upload. That has something to do with the way the ETC-utility class in Android works and me being lazy.
-
Just a quick thanks for the updates!
Some really cool stuff here.
Seems to have fixed a transparency issue I was having :)
-
Any progress on implementing Shader Attributes? i.e. use of functions GLES20.glVertexAttribPointer and GLES20.glEnableVertexAttribArray
No rush, just wandering :)
-
Any progress on implementing Shader Attributes? i.e. use of functions GLES20.glVertexAttribPointer and GLES20.glEnableVertexAttribArray
Progress implies that i wanted to add this...did i? I can't remember ATM. I'll add it, if somebody needs it. So far, nobody did.
-
The GLSL Docs mention 'Note: Because jPCT-AE doesn't support vertex attributes for external usage ATM, there are no setters for these. If you need additional data of that kind, consider baking it into a texture instead'
If it's not a hassle Attribute support would be great. I would like to use a shader that uses a large array in java code, unless there is a way to add a float[1000] into the shader program itself?
Here is the shader I would like to use:
http://opengles-book-samples.googlecode.com/svn-history/r49/trunk/Android/Ch13_ParticleSystem/src/com/openglesbook/particlesystem/ParticleSystemRenderer.java
-
I haven't looked at the shader, but...do you just need an array of floats that you access in the shader somehow or do you need them per vertex as attributes?
-
Below is the vertex shader, the three attributes are 1000 in length stored in an array of floats uploaded to the shader as an array with pointers pointing to each of the three attributes... at least that's what I understand. If you open the java link it has the shader program and array code near the top.
uniform float u_time;
uniform vec3 u_centerPosition;
attribute float a_lifetime;
attribute vec3 a_startPosition;
attribute vec3 a_endPosition;
varying float v_lifetime;
void main()
{
if ( u_time <= a_lifetime )
{
gl_Position.xyz = a_startPosition + (u_time * a_endPosition);
gl_Position.xyz += u_centerPosition;
gl_Position.w = 1.0;
}
else
gl_Position = vec4( -1000, -1000, 0, 0 );
v_lifetime = 1.0 - ( u_time / a_lifetime );
v_lifetime = clamp ( v_lifetime, 0.0, 1.0 );
gl_PointSize = ( v_lifetime * v_lifetime ) * 40.0;
}
-
I see. I'll try to add it, when i find the time.
-
Is it possible to add a setting to Virtualizer to only save to/load off sd card if the device is low on memory?
-
I can share my class for loading textures if you want... it does not need any extra time, you can load/reload textures in specific quality and you can use it for load all textures if is changed context...
-
Is it possible to add a setting to Virtualizer to only save to/load off sd card if the device is low on memory?
Sounds pretty shaky to me...you can't be sure that this operation is able to complete if you are low on memory anyway. I would rather detect the available memory and adjust usage of the Virtualizer in your own app. Because you know, what you are doing...the Virtualizer doesn't.
-
Version 1.26 has been released!
Change log:
Reduced memory usage.
Fixed a rare sorting issue with sorting transparent objects in combination with objects with user shaders.
Fixed a flaw with fogging when making multiple calls to draw() without calling renderScene() in between.
Added support for loading normals from OBJ files.
Improved performance when using multiple render targets.
Added support for nPot-textures by introducing a new class, NPOTTexture.
Added clearColorBufferOnly() to FrameBuffer.
Added a new class DepthBuffer to allow for sharing of depth buffers between render targets.
Added support for a projectionMatrix uniform to shaders.
Fixed Object3D constructor for arrays.
Added visibility setter and getter to Polyline.
Changed behaviour when setting the near plane. You don't have to manually adjust the fov anymore.
Changed TextureManager.preWarm() to make it ignore textures without any texels.
Fixed trilinear filtering on compressed textures.
Fixed stripping of objects with dynamic uv coordinates.
Fixed a problem in the obj-loader with loading empty material definitions.
Fixed a crash in the PolygonManager when adding a texture with no texture stages left.
Fixed name parsing from OBJ files.
SkyBox doesn't crash on missing textures anymore.
Added a method to get the projection matrix to Camera.
Fixed a bug in the DeSerializer that assigned a dummy texture where it shouldn't assign anything.
Fixed an issue with texture stages not handled correctly in ES 2.0 mode in some cases.
GLSLShader can handle updates to implicit uniforms (the ones that jPCT-AE injects by itself if present) in the IRenderHook implementation.
Fixed a problem where texture stages weren't initialized correctly in some cases when cloning a multi-textured object.
Fixed a flaw with ellipsoid collision detection on scaled objects.
Additional information can be found here: http://www.jpct.net/forum2/index.php/topic,3114.0.html (http://www.jpct.net/forum2/index.php/topic,3114.0.html)
In addition to the changes mentioned above, the examples in this version should run fine again on later version of the Android SDK. And there's an experimental switch in Config (Config.cacheCompressedTextures) to cache compressed textures on your sd.
-
Some testers needed!
If somebody finds the time, please try this version: http://jpct.de/download/beta/jpct_ae.jar (http://jpct.de/download/beta/jpct_ae.jar)
Looking at the renderer's code, i found a section that looked like a relic from the desktop version to me that caused nothing but unneeded state changes. In the version posted above, i've simply removed all that code. It seems to work fine for me, but i'm not 100% sure if this code was really pointless in all situations, so i would like to get some feedback from others. Thank you for your time.
-
My game is running without any problem ;)
-
i will try it tonight or tomorrow
-
works fine for me
-
all seems ok on both N7 and N1
-
Good news! I'll consider it save then to remove that code.
-
Version 1.27 has been released!
Change log:
Fixed Object3D.wasVisible().
Added get?Axis()-methods to Object3D that take a vector to be filled as additional parameter.
Added a setAdditionalColor()-method to Object3D that takes ints instead of Color-instances.
Fixed a problem with blitting and Polyline in GLES 2.0 mode.
Added the option to dispose a light.
Changed behaviour of Object3D.align(...) to create less garbage.
Ported FrameBuffer.resize() from jPCT to jPCT-AE.
Changed Config.glDither default to true.
Added rotateAxis() to SimpleVector.
Added reproject2D3DWS-methods to Interact2D that include a z-parameter.
Fixed some documentation flaws.
Fixed a flaw in light sorting when distance override is being used.
Reverted the changed fov behaviour when setting the near plane that 1.26 introduced.
Introduced a method to Camera to adjust the fov to a changed near plane.
Added new class VertexAttributes and a method to Mesh to add them.
Added an option to Polyline to draw points instead of lines.
Improved performance of ray-polygon collisions and distance calculations.
Added the option to apply a viewport offset to a render target to Config.
Fixed SimpleVector.reflect() to not return *-1 of the reflection vector.
Fixed culling when virtual dimensions have been set.
Added some methods to make jPCT and jPCT-AE more compatible to each other.
Removed the lower texture size limit of 8*8.
Improved performance for scenes with many transparent objects.
Fixed setting a texture in the PolygonManager on an object that uses less stages than Config allows.
Improved performance and accuracy of PolygonManager.getTransformedNormal(<int>);
General performance and memory improvements.
Removed the internal SimpleVector caching, because it wasn't doing any good.
-
Hello. Please tell me, is it planned to support the shadows in jPCT-ae?
-
Yes, it's planned for the next release but there's no fixed time schedule for it.
-
> Changed Config.glDither default to true.
Could you explain the reason?
> Removed the internal SimpleVector caching, because it wasn't doing any good.
So, "new SimpleVector" and "SimpleVector.create()" are the same now, right? Will "new SimpleVector" cause many GC? In my game, I will create some SimpleVectors per loop(update).
-
> Changed Config.glDither default to true.
Could you explain the reason?
It was false before, because on some really old devices (G1 and similar), it was slightly faster this way. However, it might cause additional color banding and on current and last generation devices, it's doesn't matter anyway. So by setting it to true, you'll get improved image quality without a performance impact.
> Removed the internal SimpleVector caching, because it wasn't doing any good.
So, "new SimpleVector" and "SimpleVector.create()" are the same now, right? Will "new SimpleVector" cause many GC? In my game, I will create some SimpleVectors per loop(update).
Yes, they are now doing the same thing. Creating new SimpleVectors (or any other kind of obejcts) in a loop should be avoided if possible. If you create only a few instances per frame, it shouldn't matter that much though.
-
I've just updated the zip. The engine's jar remains the same, but the documentation was missing some new classes by accident.
-
A question :
ART is supported by jpct ? 8)
-
Yes, it works without a problem.
-
WOW :D