As collision-detection-algorithms are not implemented for QuadMesh (caution: QuadMesh!=Quad) we need something like a warning! Actually I think that mostly people using HottBJ-Exporter might find this problem. I quite often forget to convert the mesh to triangles and then wonder why the collision is not working. I have for me decided to throw an exception to notify me about this. Might be bit drastic, but as logger-output is very fast overseen it seems to me the best way. Here a patch that is more a suggestion or a first approach. What is the rest of the community thinking how to handle not implemented methods (there might be more of such cases??).
Index: src/com/jme/scene/QuadMesh.java
===================================================================
--- src/com/jme/scene/QuadMesh.java (revision 4792)
+++ src/com/jme/scene/QuadMesh.java (working copy)
@@ -381,13 +381,13 @@
@Override
public void findCollisions(
Spatial scene, CollisionResults results, int requiredOnBits) {
- ; // unsupported
+ throw new RuntimeException("FIND COLLISIONS NOT IMPLEMENTS FOR QUADMESH! ("+toString()+")");
}
@Override
public boolean hasCollision(
Spatial scene, boolean checkTriangles, int requiredOnBits) {
- return false;
+ throw new RuntimeException("hasCollision NOT IMPLEMENTS FOR QUADMESH!");
}
}
I think this is a good idea but the message should probably be more direct like "Not available for QuadMesh, please use triangles". I'm not totally sure about a RuntimeException though, that does seem a bit extreme, as you note.
ttrocha said: Might be bit drastic, but as logger-output is very fast overseen it seems to me the best way.
A bit off topic, but its interesting you bring this up as I was just thinking the same thing when searching through a zillion lines of "INFO: Node Created". What do you think of using verbosity levels?
Well,…thinking about the problem again, I don't think a runtime-exception is too drastic as actually you want to use a functionality that does not exists. And that should not just passed with an error-logentry. Especially collision-detection which might have so many different other error-sources…
The good thing with runtime-exceptions is that you don't have to mark your method with "throws …" and therefore don't have to catch it if you don't want to.
Well,..thinking about the problem again, I don't think a runtime-exception is too drastic as actually you want to use a functionality that does not exists. And that should not just passed with an error-logentry. Especially collision-detection which might have so many different other error-sources....
The good thing with runtime-exceptions is that you don't have to mark your method with "throws ...." and therefore don't have to catch it if you don't want to.