In my game, the user has to click at a point to place an object (mesh). I can cast a ray and find the horizontal point where the object can be translated and then attached to rootNode to display it. However the problem is that if the user click too near to another object/scene_wall the object to be placed, runs into it. How can I prevent it??
I have read in Collisions and Intersections page that BoundingVolume can someone post an example, how exactly that can be used.
If you are using Bullet physics you can do a sweep test instead of ray casting to find “open air”.
http://hub.jmonkeyengine.org/javadoc/com/jme3/bullet/PhysicsSpace.html#sweepTest(com.jme3.bullet.collision.shapes.CollisionShape, com.jme3.math.Transform, com.jme3.math.Transform)
If you are using the scene graph then i don’t know 
Unfortunately I’m not using bullet physics.
I have a algorithm in mind but I’m sure there is existing code that I can use.
I’m having a look at the source.
Bounding Volume is what we need I guess…
PS: jMonkey does need to improve documentation…
CollisionResults l_results = new CollisionResults();
BoundingBox l_box = new BoundingBox(l_min, l_max);
getRootNode().collideWith(l_box, l_results);
if( l_results.size() > 0 )
…
ah!!!
Thanks a lot. This seems like working.
However I’m little confused with what exactly it returns and how to use its result. In case of a ray, it simple returns all target results that the ray collides with in its way.
However in case of collision with bounding volume the results.getCollision(i).getGeometry.getName is the BoundingVolume itself. How can a geometry collides with itself.
When I collide with with shootables it returns, the target object though in the closestCollision result and lot of other results followed by the BoudingVolume results as well.
[java] BoundingBox box = (BoundingBox) model.getWorldBound();
shootables.collideWith(box, results);
for (int i = 0; i < results.size(); i++) {
// For each hit, we know distance, impact point, name of geometry.
float dist = results.getCollision(i).getDistance();
Vector3f pt = results.getCollision(i).getContactPoint();
String party = results.getCollision(i).getGeometry().getName();
int tri = results.getCollision(i).getTriangleIndex();
Vector3f norm = results.getCollision(i).getTriangle(new Triangle()).getNormal();
System.out.println("Details of Collision #" + i + ":");
System.out.println(" Party " + party + " was hit at " + pt + ", " + dist + " wu away.");
//System.out.println(" The hit triangle #" + tri + " has a normal vector of " + norm);
}[/java]
Results - when i collide it with another shootable
[java]Details of Collision #0:
Party pizza-geom-1 was hit at null, 0.0 wu away.
Party pizza-geom-3 was hit at null, 0.0 wu away.
…
Details of Collision #101:
Party pizza-geom-3 was hit at null, 0.0 wu away.
…
Details of Collision #109:
Party pizza-geom-3 was hit at null, 0.0 wu away.
…
Details of Collision #114:
Party pizza-geom-3 was hit at null, 0.0 wu away.
…
Details of Collision #588:
Party drink-final-geom-4 was hit at null, 0.0 wu away.
…
Details of Collision #1187:
Party drink-final-geom-4 was hit at null, 0.0 wu away.
[/java]
“results.getCollision(i).getGeometry.getName is the BoundingVolume”
no… the geometry is the geometry that provided you a bounding volume. The bounding volume doesn’t know anything except that it’s a box. For example, you could create one manually with values of your choosing and it would have nothing to do with a mesh or geometry or anything. In this case, it just happens to be derived from a real Geometry but it doesn’t know that.
If you check for collisions in the scene then of course you will find the original geometry that the box came from because it collides. You need to put logic in to skip it.
<cite>@pspeed said:</cite> "results.getCollision(i).getGeometry.getName is the BoundingVolume"no… the geometry is the geometry that provided you a bounding volume. The bounding volume doesn’t know anything except that it’s a box. For example, you could create one manually with values of your choosing and it would have nothing to do with a mesh or geometry or anything. In this case, it just happens to be derived from a real Geometry but it doesn’t know that.
Ya I know that, what I’m saying is that its giving me the same geometry with which I’m shooting. I want to get the target geometries.
If you check for collisions in the scene then of course you will find the original geometry that the box came from because it collides. You need to put logic in to skip it.
I think, you misinterpreted my question. I’m not getting any normals etc for collisions and I’m having hard time understand what collision points its returning (Bounding volume is a big object unlike ray as a very thin object)
I want to know what results mean when I collide a BoundingVolume instead of a ray. The interpretations are clearly depicted for the case of a ray but not for BoundingVolume.
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:collision_and_intersection
This is what I want for BoundingVolume
CollisionResult Method Usage
getContactPoint() Returns the contact point coordinate on the second party, as Vector3f.
getContactNormal() Returns the Normal vector at the contact point, as Vector3f.
What is the normal, contact point, and distance in this picture?
Hint: there is no answer.
“Ya I know that, what I’m saying is that its giving me the same geometry with which I’m shooting. I want to get the target geometries.”
And I was telling you why. And your statement is still incorrect. It is not getting the same geometry that you are shooting because you are not doing a collision check from geometry to geometry.
You are getting a bounding volume that is coincidentally the same as one of your geometries… and so of course you will get that geometry as a collision. It is up to you to skip it.
…if that wasn’t part of your question then why include it.
But then what are collision results in the picture?
I guess it should be just one, the red box.
But in the results it shows two parties (red box and blue box)
and it shows me like 1100 collision results, which should have some interpretation.
What are all of them representing??
PS: I included that to depict that results are hard to understand in case of bounding volume.
@simar.i3r said: But then what are collision results in the picture? I guess it should be just one, the red box.
That would depend on where the boxes came from. If they both came from geometry then there will be two collisions.
@simar.i3r said: But in the results it shows two parties (red box and blue box) and it shows me like 1100 collision results, which should have some interpretation. What are all of them representing??PS: I included that to depict that results are hard to understand in case of bounding volume.
I can’t see what your scene looks like so I can’t comment for sure… but printing the world bounds of the collisions and the box you are using to collide might help. Note that none of this may be doing what you expect since all of these boxes will of course be axis-aligned. I don’t know enough about your use-case to know if that is useful or not.
ok
Thanks a lot. I really appreciate you trying to help me. My apologies if the question is vague and inchoate.
I have attached a screenshots, if that makes the question clear.
Please let me know the best way I can prevent ‘‘running into’’ in 2nd and 3rd image.
In the first image the game is ready to place things in the scene.
<cite>@pspeed said:</cite> "results.getCollision(i).getGeometry.getName is the BoundingVolume"no… the geometry is the geometry that provided you a bounding volume. The bounding volume doesn’t know anything except that it’s a box. For example, you could create one manually with values of your choosing and it would have nothing to do with a mesh or geometry or anything. In this case, it just happens to be derived from a real Geometry but it doesn’t know that.
If you check for collisions in the scene then of course you will find the original geometry that the box came from because it collides. You need to put logic in to skip it.
I finally got what you are trying to say. I’m actually a beginner with no experience in graphics and I was not very clear with the concept of bounding volume.
Reading carefully the tutorials and related articles, I got the idea…
@simar.i3r said: I finally got what you are trying to say. I'm actually a beginner with no experience in graphics and I was not very clear with the concept of bounding volume. Reading carefully the tutorials and related articles, I got the idea..
Cool. 
I was running out of different ways to say it.
<cite>@simar.i3r said:</cite> ok Thanks a lot. I really appreciate you trying to help me. My apologies if the question is vague and inchoate. I have attached a screenshots, if that makes the question clear.Please let me know the best way I can prevent ‘‘running into’’ in 2nd and 3rd image.
In the first image the game is ready to place things in the scene.
But I would still like to have your ideas on how you would tackle the problem.
Note: I will run this simulation android.
I might avoid collideWith() completely and do my own bounding volume checks. If the object I’m colliding overlaps something else then I’d have the ability right there to decide what to do about it.
…but you seem to already be having problems getting collideWith() to return proper results which means there may be other issue with your setup that will still manifest if done a different way. Hard to say.
I have actually got collideWith working well and I’m able to avoid the collision between pizza and burger (objects in the picture) but in case of a wall which is same object as floor, I’m having trouble distinguishing between them. How would I ever be able to decide that whether I collided with floor or wall??
I can do that somehow, my problem is solved.
@simar.i3r said: I have actually got collideWith working well and I'm able to avoid the collision between pizza and burger (objects in the picture) but in case of a wall which is same object as floor, I'm having trouble distinguishing between them. How would I ever be able to decide that whether I collided with floor or wall??I can do that somehow, my problem is solved.
You’ll never be able to do it this way, actually. The bounding volume will incorporate both the floor and the wall and all space in between.
You’d have to do mesh->mesh collisions or separate the wall and the floor. I think the bullet support can do mesh->mesh but that’s a whole other can of worms to open.
<cite>@pspeed said:</cite> You'll never be able to do it this way, actually. The bounding volume will incorporate both the floor and the wall and all space in between.
- Hmm and thats because the scene’s bounding volume is complete space enclosing the scene. I thought we can do BoundingBox and Mesh collisions.
- Can I use submeshes somehow or importing two separate models say vertical objects(walls) as one and horizontal objects(floor and slabs) as one, aligning them carefully to reproduce the scene. Then I hope I would be able to distinguish between them if I do some hack…
You’d have to do mesh->mesh collisions or separate the wall and the floor. I think the bullet support can do mesh->mesh but that’s a whole other can of worms to open.