Transition code away from batches(jme 1)

thinking about moving over to jme2 but would have to port Simple physics as well, not really clear

on the process, so have would rewrite the code below to fit jme2, I have easier time figuring stuff out with a visual example. in no real hurry since I'm working well with jme1 but that time may come.



any help is appreciated

TIA



   private Spatial mesh;
   
   private TriangleBatch batch;
   
   private int trianglePerNode;
   
   /**
    * Octree's public construtor. Use the trianglePerNode parameter to fine tune
    * the number of nodes according to the size or triangle count of your mesh.
    * @param mesh Spatial node that defines it's world translation/rotation
    * @param batch TriangleBatch as triangle data source
    * @param trianglePerNode Max number of triangles in a node
    */
   public Octree(TriMesh mesh, int batchIndex, int trianglePerNode) {
      this.mesh = mesh;
      this.batch = mesh.getBatch(batchIndex);
      this.trianglePerNode = trianglePerNode;
      BoundingBox bb = new BoundingBox();
      ArrayList<TriangleBatch> batches = new ArrayList<TriangleBatch>();
      batches.add(batch);
      bb.computeFromBatches(batches);
      
      //Transform and scale to node's coordinates
      float largeSize = bb.xExtent;
      if (bb.yExtent > largeSize) {
         largeSize = bb.yExtent;
      }
      if (bb.zExtent > largeSize) {
         largeSize = bb.zExtent;
      }
      Vector3f scaled = mesh.getWorldScale().mult(largeSize);
      largeSize = scaled.x;
      if (scaled.y > largeSize) {
         largeSize = scaled.y;
      }
      if (scaled.z > largeSize) {
         largeSize = scaled.z;
      }
      this.boundingBox = new BoundingBox(mesh.localToWorld(bb.getCenter(), new Vector3f()), largeSize,largeSize,largeSize);
      
      this.triangleData = new ArrayList<Integer>();
      for (int i =0; i< batch.getTriangleCount(); i++) {
         this.triangleData.add(i);
      }
      
   }

took few minutes on the weekend, broke a copy of jme1 and compared it with jme2 and got simple physics working, can upload if anyone is interested.



I still can't help but feel that I left a scalpel in the patient some where :expressionless:



a question though-:



because batches are gone, I had to calculate the bounding from the tri-data

bb.computeFromTris(mesh.getTriangleIndices[b](indices)[/b], meshdata.get(0), 0, meshdata.get(0).getTriangleCount());



if I declare indices as an instance variable it works without me having initialize the array, if I declare it locally I have to initialize the array

int[] indices = new int[mesh.getTriangleCount()];



the question 1 what the difference,and 2 which is better/safer

the code above as it stands now


        private Spatial meshobject;
   
   private TriMesh mesh;
   
   //private int[] indices;
   
   private int trianglePerNode;
   
   /**
    * Octree's public constructor. Use the trianglePerNode parameter to fine tune
    * the number of nodes according to the size or triangle count of your mesh.
    * @param mesh Spatial node that defines it's world translation/rotation
    * @param batch TriangleBatch as triangle data source
    * @param trianglePerNode Max number of triangles in a node
    */
   public Octree(TriMesh mesh, int batchIndex, int trianglePerNode) {
      this.meshobject = mesh;
      this.mesh = mesh;
      this.trianglePerNode = trianglePerNode;
      BoundingBox bb = new BoundingBox();
      ArrayList<TriMesh> meshdata = new ArrayList<TriMesh>();
      meshdata.add(mesh);
      //bb.computeFromBatches(meshdata);
      int[] indices = new int[mesh.getTriangleCount()];
      bb.computeFromTris(mesh.getTriangleIndices(indices), meshdata.get(0), 0, meshdata.get(0).getTriangleCount());
      
      //Transform and scale to node's coordinates
      float largeSize = bb.xExtent;
      if (bb.yExtent > largeSize) {
         largeSize = bb.yExtent;
      }
      if (bb.zExtent > largeSize) {
         largeSize = bb.zExtent;
      }
      Vector3f scaled = mesh.getWorldScale().mult(largeSize);
      largeSize = scaled.x;
      if (scaled.y > largeSize) {
         largeSize = scaled.y;
      }
      if (scaled.z > largeSize) {
         largeSize = scaled.z;
      }
      this.boundingBox = new BoundingBox(mesh.localToWorld(bb.getCenter(), new Vector3f()), largeSize,largeSize,largeSize);
      
      this.triangleData = new ArrayList<Integer>();
      for (int i =0; i< meshobject.getTriangleCount(); i++) {
         this.triangleData.add(i);
      }
      
   }



there are issues to consider though


  1. higher triangles per octree node will improve loading time, but negatively affect simulation accuracy and vice versa. e.g.  a terainpage made up of four block took what seemed like 10 plus minutes to process.



    perhaps there could be a way to save the octree collision data, since the octree build method can only be called once per scene.



    2)there are still collision failures but they seem specific to particular faces or edges or could simply be a matter of fine tuning but again the octree build time comes into play.



    things to consider 

I agree. As soon as I get some time I will get rid of ode in my app and replace it with simplephysics.

Can you post your complete port? For some reason I can't get it to work…



EDIT: Nevermind! It was the changes in the Plane class that caused the issue… Anyway, this is one really useful library, it's got wall and slope sliding, wall collision, walking on terrain, etc. I am sure nearly every 3D game will find a use for this; unless it uses the more advanced jME-physics.

cool man, did u get it working with the plane class as it stands now

did u do anything different that might be interesting/useful, as I have said before…not the best coder, but always interested in learning and getting better…guess I did passable work there, good for me :smiley:


I fully agree that the SimplePhysics Library should be part of the main jME distribution.  It resolves so many basic collision avoidance and detection issues that it is nearly invaluable for those who want wall/object sliding, slope sliding/climbing, terrain following, etc. but do not want to take on or have need for the full blown jME Physics package. 

Ten minutes is a long time!  I will probably have more to say about this in a couple of weeks when I get out of the combat zone and back into field/quest mode in my lab/game and start to deal with the simple physics in a more intense way; however, I don't use procedurally generated terrain pages but models and so my triangle counts are probably going to be much lower than what you are running into, mcbeth. 



That aside, I am very interested in working on the problem to make our already happy SimplePhysics library even better!