Hi,
I am having problems trying to use collideWith():
scene.collideWith(mouseRay, pickResults);
raises the following exception:
28/09/2010 00:38:48 com.jme3.app.Application handleError
GRAVE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
java.lang.IndexOutOfBoundsException: 8465
at java.nio.DirectIntBufferU.get(Unknown Source)
at com.jme3.scene.mesh.IndexIntBuffer.get(IndexIntBuffer.java:25)
at com.jme3.collision.bih.BIHTree.(BIHTree.java:80)
at com.jme3.collision.bih.BIHTree.(BIHTree.java:94)
at com.jme3.scene.Mesh.createCollisionData(Mesh.java:432)
at com.jme3.scene.Mesh.collideWith(Mesh.java:443)
at com.jme3.scene.Geometry.collideWith(Geometry.java:200)
at com.jme3.scene.Node.collideWith(Node.java:496)
at com.jme3.scene.Node.collideWith(Node.java:496)
at com.jme3.scene.Node.collideWith(Node.java:496)
it only seems to happen when a TerrainQuad is on the scene.
Is this a bug or am I doing something wrong?
Thanks in advance
This might be due to the fact that terrain meshes are not consisting exclusively of closed triangles while they are mipmapped… Thanks for the report, we will have to check on this.
Cheers,
Normen
That’s probably from the terrain being made of triangle strips. I will have to put in a custom collide method to resolve this issue. Hang tight for a few days 
Thanks guys, I’ll be waiting for the fix then.
Thanks, I added this issue to the issue tracker.
The benefits of having a heightfield are clearly great if you’re using your terrain in a static way. I just started using jme3 a few hours ago to create a small proof of concept in the domain of terrain morph. I would have been much faster if some kind of terrainToMesh converter would have been available. However I’ll wait now for a while, checking out id tech 3. You don’t have to create this converter for me, as I just went by. But if you do so, please post some benchmarks with big terrains (like 8mio triangles or something like that). That would be very interesting.
cheers!
Hi all
Actually quiet easy workaround: save a mesh of the terrain fetching every TerrainPatch child node’s mesh… (recursively). Do this on init! Otherwise your vm will kill you for casting and instancechecking in the render loop…
After having this mesh cached locally, you can just iterate over its Triangles. No big deal. You loose a bit of memory. But for the moment that should be okay.
cheers sotcommy
damn why is the LODGeomap mesh creating method not actually creating the mesh? that would solve many problems… can you tell me the idea behind that?
cheers 
sotcommy said:
damn why is the LODGeomap mesh creating method not actually creating the mesh? that would solve many problems... can you tell me the idea behind that?
cheers :/
What do you mean it's not creating the mesh?
the mesh consists of not correctly set up triangles. check the sourcecode, you will see what i mean. that’s the reason why getting the mesh from the terrainpatches and using it for collision ends up in checking collision with X (0,0,0), (0,0,0),(0,0,0) triangles 
The mesh is using a triangle strip with degenerate triangles. Colliding with degenerates does not work and that causes the error. That’s why we have to use the heightfield for collision detection; it is also quicker using an axis-aligned heightfield instead of a straight triangle mesh for collision.
yep i see that. but you should provide a way to get the mesh from a terrain. i would find that quiet important.
cheers
A method could be made to create one giant mesh of the terrain. If enough people want it I will create that. But it would have many downsides, mostly because the terrain can get really, really large, and many of the operations done on the the terrain are more effecient using just the heightfield, especially collision.
The terrain is made up of many meshes for several reasons: the first is for culling so we don’t have to render every triangle. The other reason is for LOD control. A single mesh wouldn’t benefit from these and would have to be used for quite a special case, and that would be why I am hesitent to store a giant mesh in the terrain tree, at least for now.
I was able to have the same problem with a model as well,
strange thing is, that it happens with the triangleindex -1525 or similar (but NEGATIVE!!)
I will drop a simpletestcase in a few hours when I’m back home
heyho
i just wrote a blog post about a custom octree style algorithm, which is very simple and easy to customize. maybe a few people reading this thread want to check it out for mesh collision. it’s not about optimizing what’s in the system so far, but providing a few snippets if someone want to create his own algorithm.
http://www.byteality.ch/blog/?p=108
cheers!
EmpirePhoenix:Right now the collision won’t work for any type bounding volume or mesh. I almost have Ray collision working with it and should be able to commit that today. I haven’t had much time this week so I’m a little behind on where I planned to be.
In the mean time, you can make the terrain a bullet mesh and all of your objects bullet meshes, then just use physics for collision.
Sotcommy:Cool blog post. I will share it with the list, I’m sure there are several people that would like to read it.
cheers,
Brent
Ah yeah, there was another thing i wanted to tell you guyz: It’s really nice that the Triangle caches its center position right out of the box. But you should add some kind of dirty flag if any of the 3 vertices changes. It’s quiet inconsistent otherwise, I had problems there, actually thinking that the center wouldn’t be cached in your standard library. Overriding the impl’s methods is no problem, but i think it’s something that could go into the repo. (You actually just have to set the center to null again on any affecting change - that way at least direct manipulation on the triangle is handled correctly. The rest is to the law of demeter ;D)
cheers!
Yep it should be changing the center any time one of the vertexes changes. I will fix that this week and get it to use a dirty flag. Thanks for finding that one sotcommy.
no problem, keep up the good work!