Author Topic: StackOverflowError  (Read 4105 times)

Offline raft

  • quad
  • ******
  • Posts: 1966
    • View Profile
    • http://www.aptalkarga.com
StackOverflowError
« 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

Code: [Select]
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)
        ...


Online EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Re: StackOverflowError
« Reply #1 on: July 29, 2010, 08:06:46 am »
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?

Offline raft

  • quad
  • ******
  • Posts: 1966
    • View Profile
    • http://www.aptalkarga.com
Re: StackOverflowError
« Reply #2 on: July 29, 2010, 03:09:54 pm »
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 ?

Online EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Re: StackOverflowError
« Reply #3 on: July 29, 2010, 04:33:41 pm »
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.

Offline raft

  • quad
  • ******
  • Posts: 1966
    • View Profile
    • http://www.aptalkarga.com
Re: StackOverflowError
« Reply #4 on: July 29, 2010, 04:36:23 pm »
maybe a flag in Config may help comparing the results

Online EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Re: StackOverflowError
« Reply #5 on: July 29, 2010, 05:12:33 pm »
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).

Offline raft

  • quad
  • ******
  • Posts: 1966
    • View Profile
    • http://www.aptalkarga.com
Re: StackOverflowError
« Reply #6 on: July 29, 2010, 05:30:55 pm »
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 ?

Online EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Re: StackOverflowError
« Reply #7 on: July 29, 2010, 05:57:50 pm »
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.

Offline raft

  • quad
  • ******
  • Posts: 1966
    • View Profile
    • http://www.aptalkarga.com
Re: StackOverflowError
« Reply #8 on: July 29, 2010, 06:31:32 pm »
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.

Quote from: EgonOlsen
..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

Quote
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 ?


Online EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Re: StackOverflowError
« Reply #9 on: July 29, 2010, 09:15:13 pm »
Hard to guess...if your game runs fast enough with your current approach, there's not much need to change it anyway.

Offline raft

  • quad
  • ******
  • Posts: 1966
    • View Profile
    • http://www.aptalkarga.com
Re: StackOverflowError
« Reply #10 on: August 02, 2010, 07:45:34 pm »
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 ?

Online EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Re: StackOverflowError
« Reply #11 on: August 02, 2010, 09:34:24 pm »
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?

Offline raft

  • quad
  • ******
  • Posts: 1966
    • View Profile
    • http://www.aptalkarga.com
Re: StackOverflowError
« Reply #12 on: August 02, 2010, 09:53:12 pm »
i've got a NPE with new jar while merging.

Code: [Select]
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)
  ...

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

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

Online EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Re: StackOverflowError
« Reply #13 on: August 02, 2010, 10:13:21 pm »
Opps...i've updated the jar again. Maybe that one will work?

Offline raft

  • quad
  • ******
  • Posts: 1966
    • View Profile
    • http://www.aptalkarga.com
Re: StackOverflowError
« Reply #14 on: August 02, 2010, 10:22:12 pm »
yes this one works and takes less time to merge :) but still no miracle as you said

20x20: ~12 sec
30x30: ~75 sec