IndexOutOfBoundsException with Ray Collision

Hey monkeys,

I’m checking for collisions using the following, nothing really complicated I’m afraid, but getting a crash.


private boolean isOccluded() {

Ray shooter = new Ray(sunSpatial.getWorldTranslation(), sceneViewport.getCamera().getLocation().normalize());


CollisionResults colRes = new CollisionResults();

/* crash on the next line */

sceneNode.collideWith(shooter, colRes);

if (colRes.size() > 1) {

return true;

} else {

return false;






Sep 01, 2011 8:52:48 AM handleError

SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]


at java.nio.Buffer.checkIndex(

at java.nio.DirectFloatBufferU.get(

at com.jme3.collision.bih.BIHTree.initTriList(

at com.jme3.collision.bih.BIHTree.<init>(

at com.jme3.collision.bih.BIHTree.<init>(

at com.jme3.scene.Mesh.createCollisionData(

at com.jme3.scene.Mesh.collideWith(

at com.jme3.scene.Geometry.collideWith(

at com.jme3.scene.Node.collideWith(








at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(

at com.jme3.system.lwjgl.LwjglDisplay.runLoop(




Is the lack of response a silent mean to tell me something I’m doing is very wrong, or maybe a RTFM sign? :stuck_out_tongue:

I had a look and a think when you posted this but couldn’t spot anything I’m afraid - I’m not the right person to help though :slight_smile:

By chance does your sceneNode contain any geometry that uses triangle strips or fans ?

Or there is an outside chance this thread may help point you in round about the corrects direction.

I can’t stand getting blocked by these sorts of issues, good luck with it.

thetoucher said:
I can't stand getting blocked by these sorts of issues, good luck with it.

Well, I'm not really blocked, but fixing this might push the lens flare I'm working on faster. ;) Off the top of my head I'm trying to remember if any of the objects in that node is having a bounded spatial... Can't remember. But should the absence of bounding boxes/spheres/volumes cause a crash? Shouldn't it just return 0 or null?

This will have to wait until tomorrow though.

Thanks anyway @thetoucher :)

From a quick look at the code I can see several issues:

  1. There are some indices in the index buffer that point to non existent vertices
  2. Some VertexBuffers are not rewind()ed… Its assumed they start at zero although there’s no check for that anywhere. I guess it should be added as some other things might not work correctly.

    Try exporting your sceneNode to a j3o and then loading it back, it should reset the offsets of the buffers so you will know if the issue is #2 or not
1 Like

Thanks @Momoko_Fan.

I found where the problem was originating from. It’s a Circle class I made based on WireSphere to draw the actual orbit of a planet in a solar system. I guess something should be done in there that it’s not doing and that’s what’s causing the Ray crash.

Now, the only thing that annoys me a bit is the fact that I’d prefer if collision check would simply skip those since they’re not “real” and wouldn’t occlude the view. This is only a visual reference for players… I wonder if I could override collideWith to skip from collision check… Of course it’d be even better if the whole mesh was done “right” so this wouldn’t crash as I intended to contribute this…

Here’s the class. Of course right now it’s completely customized for my needs, things like the number of samples should be settable at creation and not being static (at least not 720).


public final class Circle extends Mesh {

private final static int samples = 720;

private final static int zSamples = 10;

public Circle(float radius, float lineWidth) {


ShortBuffer ib = BufferUtils.createShortBuffer(samples * 4 + zSamples * samples * 2);

setBuffer(Type.Index, 2, ib);

int curNum = 0;

for (int j = 0; j < 2 + zSamples; j++) {

for (int i = curNum, k = curNum + samples - 1; i < k; i++) {

ib.put((short) i).put((short) (i + 1));


ib.put((short) (curNum + samples - 1)).put((short) curNum);

curNum += samples;







public void updatePositions(float radius) {

VertexBuffer pvb = getBuffer(Type.Position);

FloatBuffer pb;

if (pvb == null) {

pvb = new VertexBuffer(Type.Position);

pb = BufferUtils.createVector3Buffer(samples);

pvb.setupData(Usage.Dynamic, 3, Format.Float, pb);


} else {

pb = (FloatBuffer) pvb.getData();



float rate = FastMath.TWO_PI / (float) samples;

float angle = 0;

for (int i = 0; i < samples; i++){

float x;

float y;

x = radius * FastMath.cos(angle);

y = radius * FastMath.sin(angle);


angle += rate;





I’ll check if I can find a way to skip collision.

Yep, that was it.

It’s “fixed” now, but this comes back to the problem I was talking about in the previous post. There are several meshes that only exist for visual representation and shouldn’t occlude view when using a collision ray. It would be nice to be able to set a flag to false so collision isn’t attempted with certain objects.

I guess for now I’ll iterate through objects that I know should occlude in the node myself.

I’m about to invoke the wrath of the other devs, I think… but this is precisely the kind of use case the pushed me to extend Node and/or Geometry in a few places. Either ignoring collision completely or directing it to only certain children.

pspeed said:
I'm about to invoke the wrath of the other devs, I think... but this is precisely the kind of use case the pushed me to extend Node and/or Geometry in a few places. Either ignoring collision completely or directing it to only certain children.

I agree.

I started to modify some classes to implement that myself but thought better of it. I'm not at that point where I should dabble with those as it represents considerable modifications to many classes and I didn't want to end up doing this for nothing or having to constantly maintain the customized classes after an update.

I posted the above hoping that it would twang a chord in someone. ;)

Yeah, in my case it’s nothing fancy. I extend node and override collideWith() to just return 0. Then I can put things under that node that don’t get collisions.

That’s what I originally did, except I did it in the Circle class but then changed my mind and iterated through the planets and the ogre model myself because there are too many visual cues, most of them extending either Mesh or Geometry to bother with.

It would be so easy to just pass the node to the Flare instance and check for occlusion from there on objects where their “skipOcclusion” flag is not triggered, but oh well…