Straaaaange Problem

Well, simply put, you can’t do this. When you throw that custom Box of yours into the PhysicsObject, it will try to figure out how to put together the physical representation. So it does something like:


if (passedInGeometry instanceof com.jme.scene.shape.Box) {
    make it a box
}
else if (it's a com.jme.scene.shape.Sphere) {
   make it a sphere
}
else {
    make it a trimesh
}



And your custom box class will end up in that "else" block, since it extends TriMesh. This is the reason it "kind of" works - ODE doesn't seem to handle TriMeshes very well...

If you're using the latest CVS and really would like your object to behave like a box, you could use the other PhysicsObject constructor that takes a PhysicsType along with the Spatial. However, I'm not sure this works for StaticPhysicsObjects yet - DP said he was going to add that some time ago, so it's not impossible that it does :)

The only thing I’ve modified in the Box class is the texture coordinate generation so if I hack the Physics stuff and add my modified box into the if statement then it should work right?



(Other than being an ugly hack)

Right, shouldn’t be a problem. Replacing the references in com.jmex.physics.PhysicsEntityFactory should due.

Why can’t you just EXTEND the box class? After all, it’s an object oriented language :slight_smile:

Amen… :wink:

hmmmmm … no reason in particular I suppose haha.

hmmm … I extended the Box class. Basically just created a MapBox class which extends Box Class and then copied all the code into my MapBox class (renaming the constructors and stuff of course).



When I use the MapBox class I still get the problem where collisions aren’t detected. I checked to make sure that the MapBox is getting treated as a Box and it is.



Am I doing something wrong in the extending?

Well, does it work as you expect if you directly use a Box? Then maybe there is still an issue with the collision detection itself.

Yep … it works fine if I directly use the jME Box class.



Just doesn’t work when I use my own MapBox class which extends the jME Box but otherwise is the exact same code.

class MapBox extends Box {

public MapBox(params) {

super(params);

}

}



create an extended box like so, make sure it still works. Add the functionality you need one thing at a time. See if/where it fails.

Question on how inheritance works … probably a little off topic.





In your child class, wHen you overwrite a method in the parent class does the parent class use the overwritten method in the child class?



So for example,



I overwrite the setTextureData() method in my child class.



I’m still using the parent constructor though. Will the parent constructor make use of my overwritten setTextureData()?



It looks it won’t and that i have to overwrite the constructors as well. Since almost all the methods are private I need to overwrite all of the private methods so in effect I’m copying the whole class over.



Gotta keep testing but when I do that the collision detection doesn’t work. Really odd.



When I just do

class MapBox extends Box {
public MapBox(params) {
super(params);
}
}



it works though

Well, the parent constructor constructs - the parent! So you don’t have an object of your new class then. If you want an instance of your MapBox class, you need to call a constructor of that class. Constructors are not inherited like other methods - apart from the default constructor without parameters, if it exists.

Batman is correct, if you don’t specify a constructor in your subclass, it will use the super() constructor. If you dod specify a constructor in your subclass, but fail to call super(args), it will again call the super() constructor. In the case of TriMesh, Geometry and so forth, this would be bad because it would not be setting up the underlying arrays.

It would use the overriden method in the child class. We do that a lot in the jME core.