Hi!
I’ve made a (very) basic level editor with swing. It generates a “level”, which is made of “layers” and each “layer” contains “blocks”. The purpose is to understand how to remake a '80 or '90 isometric game like for instance Spindizzy:
So, basics first, every block is a 1x1x1 cube in a StaticPhysicsNode. Cool!
But… loading 1000 of these causes a StackOverflowError. Argh. I wonder, as there is a “TerrainPage” class to subdivide large terrains, is there a class that would only “load” nodes at a certain distance?
Increasing the memory size would not solve this issue, I mean, “java is poetry”, someone has perhaps already written a nice way to solve this…
thanks!
Though not ideal, why wouldn't increasing the memory solve this? You'd have to increase your stack size (-Xss or -Xoss if I recall). I agree though that it's not a good solution, you might try that to see if you can even get it to a size that will accommodate your scene.
Not ideal, I mean this will solve the issue until the next memory limit is reached, so the problem is the same only the scale changes… those mmorpg with thousands of items on a single "level" will load only what 's near the player I think?
I'll start thinking about a "framework" to manage a map "item-node", but I fear I've not yet a suffiscient knowledge of a what scene graph is… so, this will be an attempt 
I hope to post something working one of these days 
I was giving some advice when I was thinking the same thing…
The default VM memory is still only 64MB (which is REALLY small) just increasing it to 128 can give a WORLD of difference.
-Xmx128m
Ah I thought it was 256 by default. Good to know. However, writing this "element culling by area" sounds interesting to me, the writing has begun 
Will see if it makes sense…
I'll keep you updated!
Ok, question about this please: Is there a method to call on a node to delete it, not only detatch it from the rootNode?
something with a result like "node.destroy();" ?
thanks!
1000 static objects should not be a problem. Please post the exception stack trace.
Hi!
Ok, so the code that generates each node first:
public static Node convertLevelToJME(Level l, PhysicsSpace space) {
Node level = new Node();
for (Layer layer : l.getLayerSet()) {
Node layerNode = new Node();
layerNode.setLocalTranslation(new Vector3f(0, layer.getY(), 0));
for (Block block : layer.getBlockSet()) {
Box blockBox = new Box("Block", new Vector3f(0, 0, 0),
new Vector3f(1, 1, 1));
blockBox.setLocalTranslation(new Vector3f(block.getX(), 0,
block.getZ()));
blockBox.setModelBound(new BoundingBox());
blockBox.updateModelBound();
StaticPhysicsNode blockBoxPhysics = space.createStaticNode();
blockBoxPhysics.attachChild(blockBox);
blockBoxPhysics.generatePhysicsGeometry();
layerNode.attachChild(blockBoxPhysics);
}
level.attachChild(layerNode);
}
return level;
}
The error occurs for instance when:
- layer = 10
- size = 10
(a plain 10x10x10 cube)
Hmm I've modified my classes since I've first posted this, but a stack overflow issue is still reported.
The following occurs:
15-mars-2008 17:25:55 com.jmex.physics.impl.ode.OdePhysicsSpace addNode
INFO: PhysicsNode (null) has been added
15-mars-2008 17:25:55 com.jme.scene.Node attachChild
INFO: Child (Block) attached to this node (null)
15-mars-2008 17:25:55 com.jme.scene.Node attachChild
INFO: Child (null) attached to this node (null)
15-mars-2008 17:25:55 com.jme.scene.Node attachChild
INFO: Child (null) attached to this node (null)
15-mars-2008 17:25:55 com.jme.scene.Node <init>
INFO: Node created.
15-mars-2008 17:25:55 com.jmex.physics.impl.ode.OdePhysicsSpace addNode
INFO: PhysicsNode (null) has been added
15-mars-2008 17:25:55 com.jme.scene.Node attachChild
INFO: Child (Block) attached to this node (null)
15-mars-2008 17:25:55 com.jme.scene.Node attachChild
INFO: Child (null) attached to this node (null)
15-mars-2008 17:25:55 com.jme.scene.Node attachChild
INFO: Child (null) attached to this node (null)
15-mars-2008 17:25:55 com.jme.scene.Node attachChild
INFO: Child (null) attached to this node (null)
15-mars-2008 17:25:55 com.jme.scene.Node attachChild
INFO: Child (null) attached to this node (rootNode)
An unrecoverable stack overflow has occurred.
This same code, executed with the following parameters:
- layer = 9
- size = 10
(10x5x10 cubes) does not cause the issue.
This can't be related to hardware? Mine is not the newest, a mobility radeon 9600.
Do you have dynamic nodes in your scene? Probably a really big one hitting multiple static ones?
Try not to create any dynamic node and check if the error persists.
ok, I've stripped down my program to the strict minimum, it can be run from any jme+physics installation (unlike the previous thing):
package experimentation.environment;
import com.jme.app.AbstractGame;
import com.jme.bounding.BoundingBox;
import com.jme.math.Vector3f;
import com.jme.scene.Node;
import com.jme.scene.shape.Box;
import com.jmex.physics.StaticPhysicsNode;
import com.jmex.physics.util.SimplePhysicsGame;
public class BasicPhysicsGame extends SimplePhysicsGame {
public static void main(String[] args) {
new BasicPhysicsGame();
}
public BasicPhysicsGame() {
this.setDialogBehaviour(AbstractGame.ALWAYS_SHOW_PROPS_DIALOG);
this.start();
}
@Override
protected void simpleInitGame() {
Node level = new Node();
for (int i = 0; i < 10; i++) {
Node layerNode = new Node();
layerNode.setLocalTranslation(new Vector3f(0, i, 0));
for (int j = 0; j < 10; j++) {
for (int k = 0; k < 10; k++) {
Box blockBox = new Box("Block", new Vector3f(0, 0, 0),
new Vector3f(1, 1, 1));
blockBox.setLocalTranslation(new Vector3f(j, 0, k));
blockBox.setModelBound(new BoundingBox());
blockBox.updateModelBound();
StaticPhysicsNode blockBoxPhysics = getPhysicsSpace()
.createStaticNode();
blockBoxPhysics.attachChild(blockBox);
blockBoxPhysics.generatePhysicsGeometry();
layerNode.attachChild(blockBoxPhysics);
}
}
level.attachChild(layerNode);
}
rootNode.attachChild(level);
}
@Override
protected void simpleUpdate() {
}
}
Still getting the error :(
(good thing for me, it would have meant debugging...)
Hmmm, your test ran fine for me.
Nice test btw, very plug and play
hey thanks for testing
Well, perhaps it's my computer then
its my computer too then
i can create 729 boxes, until : "An unrecoverable stack overflow has occurred."
no backtrace is printed just the message.
Core-Dump or hobstad…my original question was to see if by increasing the stack size to any level if it would run? Can you test and validate this on your machine and output what you had to put in before it would work? It may be a reasonable increase, or it may be something that will happen no matter what you set the stack size to.
I actually tried setting my heap size to the default and it still ran…
Okay, so this is odd. it runs in OSX but not Windows. changing the heap size doesn't seem to help at all, tried 512MB even.
i also tried different settings, but couldn't find one that that works yet.
The stack overflow happens somewhere in:
org.odejava.ode.Ode.spaceCollide()
org.odejava.collision.JavaCollision.collide()
com.jmex.physics.impl.ode.OdePhysicsSpace.computeTimeStep()
com.jmex.physics.impl.ode.OdePhysicsSpace.update()
com.jmex.physics.util.SimplePhysicsGame.update()
Then it would seem it has nothing to do with actual allocation, but probably an infinite recursion issue in the code somewhere.
darkfrog said:
Then it would seem it has nothing to do with actual allocation, but probably an infinite recursion issue in the code somewhere.
I don't think so. It might be another stack-size dependant part of ODE - the collision detection this time. I'll double chack that...
I investigated a bit:
- you can increase the native stack size (e.g. -Xss1M and remember to spawn a new thread), then it works, but performance is really bad (10 fps here)
- you can move the boxes apart (place them at 5k; 5i; 5*k) -> larger stack size not need, performance ok (hundreds fps)
This leads me to the conclusion that the collision detection of ODE uses a large stack size (and much cpu time) if collision groups (islands) are large. And this even seems to be the case if the collision are ignored in the near callback (as it is the case for static-only stuff). A solution for this would be multiple ODE spaces. Which is currently not supported by jME Physics 2
A quick fix in jME Physics would be to put all static geoms into an own (ODE-)space and check collisions between that static space and the 'normal' space and between 'normal' and 'normal'… a better solution would be those CollisionGroups…