www.jpct.net
jPCT-AE - a 3d engine for Android => Support => Topic started by: raft on July 29, 2010, 12:46:42 am
-
happens almost immediately in a relatively large scene: 60x20 grid where each cell is a primitive box. in 20x20 it happens again but later
Uncaught handler: thread GLThread 8 exiting due to uncaught exception
java.lang.StackOverflowError
at com.threed.jpct.VisList.qsort(VisList.java:168)
at com.threed.jpct.VisList.qsort(VisList.java:172)
at com.threed.jpct.VisList.qsort(VisList.java:173)
at com.threed.jpct.VisList.qsort(VisList.java:173)
at com.threed.jpct.VisList.qsort(VisList.java:173)
...
-
Stack size is very limited in Dalvik...and so is recursion depth. I could convert the sort to be iterative but that will be slower and consumes additional memory (heap access instead of stack and i would have to keep the virtual stack in memory to avoid object creation). There's an iterative fsort-implementation lying around in the code...just deactivated. I can reenable it and see if it still works. On the other hand: Aren't 1200 single objects a bit too much for Android anyway?
-
i see. 1200 objects are surely too much, (i was just trying it) but 400 objects ?
are we talking about polygon sorting or object sorting here ? if objects, merging some objects may help i suppose. i dont know how much this will be possible, since in the course of game, some of the tiles disappear, some of them are highlighted and so on. seems as i will have problem with large levels..
i dont know much about sort algorithms. but as i recall, most (if not all) recursive algorithms can be flattened by emulating recursion. is that what you call iterative sort ?
-
It's not polygon sorting, it's sorting of compiled instances. Yes, that's what i call iterative sort when you remove the recursion. As said, i once wrote an iterative fsort implementation but never activated it, because on the desktop, it wasn't any faster. I'll enable it for AE and see if that helps and how it performs.
-
maybe a flag in Config may help comparing the results
-
Ok, i've uploaded a new AE-jar and added an option to config called flashSortThreshold. Play around with it and let me know the results.
400 Objects is still a pretty high object count for Android IMHO. I never came close to this in any application may it be on the desktop or the phone (except for particle systems of course).
-
thanks, i will try it ;D i guess this flashSortThreshold is object count threshold to activate iterative sorting, right ?
is it the object or polygon count that sounds too high ? they are just primitive box tiles, 12 polys for each. 400x12=4800 polygons.
if i somehow find a way and merge at least some of them, will it help ?
-
It neither object nor polygon count...it's compiled instance count, which is at least as high as the object count but not quite as high as polygon count.
The problem with a high object count is, that the setup work for rendering each of them creates some overhead. It's better to batch as many objects as possible in one. If they need to be split again for rendering, the object compiler will do this anyway but in a way that's more optimal for the rendering pipeline.
-
i've tried the new jar. it runs without crashing even for 60x20 scene. for 10x10 scene, it's overhead is not noticable. i tried it by setting flashSortThreshold to 15.
..which is at least as high as the object count but not quite as high as polygon count.
so in this case, sharing compiled data wont help, except for memory of course
It's better to batch as many objects as possible in one. If they need to be split again for rendering, the object compiler will do this anyway but in a way that's more optimal for the rendering pipeline.
mm, this requires some thought and trials i suppose. as i said, some tiles are highlighted, some others disappear or so. highligting can be handled by other means (an additional plane maybe, or via PolygonManager) but disappearing tiles should be different objects.
with a wild guess, how much gain would you expect from merging 20x20 scene into one ? when this tiles are close to each other or spread around the sccene ?
-
Hard to guess...if your game runs fast enough with your current approach, there's not much need to change it anyway.
-
i've made some tests and seems as merging objects results in enormous fps gain. but it takes too long to merge objects.
some numbers:
20x20 grid
umerged/merged 9/43 fps. ~19 secs to merge
30x30 grid
u/m 4fps/33 fps ~1.5 minutes to merge
30x40 grid
u/m 3/26 fps > 3min to merge
40x40 doesn't even merge throwing OutOfMemory
30x40 grid x 12 poly/tile = 14400 polygons. 26 fps is very impressive. jPCT and N1 has definetely has the power to render such a scene. however object count severely damages this.
isn't it possible to somehow hack this ? for example compiling multiple objects as one ? or something else ?
-
Can't you merge the level data on the desktop and serialize it using the DeSerializer class? I'm only using objects of that kind, because loading them that way is the fastest way possible (and with the least memory consumption). I've also uploaded a new jar of AE that improves merging performance, but i don't think that this will help much (if any).
To evaluate if some kind of fierce hack is even possible, i have to know more about the structure of that objects. Are they all using the same texture for example?
-
i've got a NPE with new jar while merging.
Caused by: java.lang.NullPointerException
at com.threed.jpct.Object3D.appendToObject(Object3D.java:5961)
at com.threed.jpct.Object3D.mergeObjects(Object3D.java:453)
at com.threed.jpct.Object3D.mergeAll(Object3D.java:473)
...
To evaluate if some kind of fierce hack is even possible, i have to know more about the structure of that objects. Are they all using the same texture for example?
At the moment yes. But this is just a performance test , not the real game and tiles.
Can't you merge the level data on the desktop and serialize it using the DeSerializer class? I'm only using objects of that kind, because loading them that way is the fastest way possible (and with the least memory consumption).
sure i can. but that will cost me a few things. i prefer text based levels for both small size and simplicity. i can still use them on desktop and serialize objects, but that way level size will get bigger. and manupulating different objects are much simpler. highlighting etc.
i guess i can fit my game to what is possible. my main point is, you made a fantastic job with compiled objects. maybe there is a way to benefit that performance and still preserve usage simplicty of jPCT with seperate objects.
-
Opps...i've updated the jar again. Maybe that one will work?
-
yes this one works and takes less time to merge :) but still no miracle as you said
20x20: ~12 sec
30x30: ~75 sec
-
Well, it's actually better than i had expected... ;)
Oh, and while you are there: The Android version of GLFont doesn't seem to set the content of the charWidths-array, so that the width of any string is always 0 when using getStringBounds(). Do you have a working version of this?
-
sure. here it's
http://aptalkarga.com/download/android/AGLFont.java
this version also accepts char arrays instead of strings to avoid string creation if possible
so what do you think of compiling multiple objects into one ?
-
oops, it references a missing class
http://aptalkarga.com/download/android/Rectangle.java
-
Thanx!
Compiling multiple objects into one isn't really possible, because even if geometry and texture usage is the same, the transformations are not. You can't pack everything into one compiled chunk without making the use the same transformation matrix, which doesn't make any sense for multiple objects.