Stack Overflow with Blitz3D & JV-ODEArchives Forums/Blitz3D Bug Reports/Stack Overflow with Blitz3D & JV-ODE
I was doing some tinkering with the Demo's for JV-ODE (With Blitz 3D 1.98), specifically Spheres, which just repeatedly drops spheres onto a plane and I get a Stack Overflow from Blitz after increasing the drop rate when I get to about 1500 objects.
I realize that my frame computation time at this stage is high and usefulness of 1500 balls rolling around a plane had limited uses (=P), but my RAM was far from exhausted and I would have anticipated that this would have been the sole restriction for this type of activity.
Is this expected behaviour, can the stack be increased, or it the demo doing something functionally recursive (apart from adding another ball to a list)?
| I would expect that to happen.|
I believe one could recompile with a larger stack, but as you pointed out it would be of little practical use.
I was looking at doing some 'many thousand object' experiments and just playing it back after computation even if each frame took several minutes.
I wonder if it would be possible to get the stack size as a command line argument (that defaults to current value) that was dynamically allocated so you could fully utilize your machine with more objects if you chose?
| The problem you are experiencing is due to creating too many objects which are inside each others collision zone. It would also cause horrendous slow down.|
To stop the Stack Overflow occurring you need to make sure they don't overlap during creation.
Btw, this should be in the JV-ODE threads really as it's not a Blitz3D issue ;)
| Thanks VIP3R,|
I wasn't sure if it would be a JV-ODE issue as I figured it just wrapped the ODE library and there would be no reason there would be a limit the amount of objects, you're simply constrained by your own resources.
From what I see of the code, aren't the object already created in such a way that they don't overlap upon creation, i.e. X,Y = Rand(-8 to 8)? From what you said, I guess that would mean I could create 10,000 even spaced spheres for example and they would sit on a plane quite happily (this is not the restriction), but if I put a wall around them all and rolled them into one corner, the system would start to fall over once the collision zone intercepts became bigger than the stack could handle?
I realize the horrendous slowdown, but that is acceptable for what I'm doing. Any way I'll have to delve deeper in to the documentation of how the collision detection (zones) work.
Thanks for the feedback. =)
[I'll Repost this in a JV-ODE Thread]
| Replied here :) |
| 64640 dll messages seems a limit here too with a network dll in a userlib...|
I mean, exactly after 64640 counted incoming messages (call to the dll are less, the messages are 5-10 per call) and the number is always the same after many try, the application blocks with a "overflow stack" error prompt.
who knows why... ?