I'm having a problem where I can't figure out how to use Jme3 to attach a Ray to a Vehicle. Basically I'm trying to make a "sensor" stuck on the front of the TestPhysicsCar.java car. I tried adding code directly from the TestRayCollision.java example but I can't attach anything but a Geometry or Spacial to the PhysicsVehicleNode.
I added this just after the last wheel was added in TestPhysicsCar.java:
Ray ray = new Ray(Vector3f.ZERO, Vector3f.UNIT_X);
player.attachChild(ray); //throw error because you can't pass a Ray here
Any help would be greatly appreciated. I'm rather new to this stuff, so I may be missing something very basic. Please bear with me.
I think the GhostNode will be much easier to implement and much faster to execute. I like the idea of just using the ghostNode to detect a collision, then figuring out where it is.
What about having a stack of sequentially smaller cylinders would better approximate a cone shape?
I also tried replacing the box with a cylinder in the TestGhostObjec.java example on the June 28th build and I'm getting problems…
I can do this:
Cylinder boxGeom = new Cylinder();
but I get errors in the " Geometry ghostGeom = new Geometry("ghostVisual", boxGeom);" line (since the cylinder has no dimensions.)
When I try to give dimensions to the Cylinder when I create it, like this:
Cylinder(int axisSamples, int radialSamples, float radius, float height) <-- from JME3 javadoc
Cylinder boxGeom = new Cylinder( 6, 18, 5f, 10f);
it says the following:
Cannot find symbol
Symbol "constructor Cylinder(int,int,float,float)
Location: class com.bulletphysics.demos.applet.Cylinder
If I try to specifically add the Cylinder library (import com.jme3.scene.shape.Cylinder;), it says:
"com.bulletpgysics.demos.applet.Cylinder is already defined in a single-type import."
This also doesn't change anything.
Is this a problem with JME3 or is it again a misunderstanding on my part?
…
I think you have a wrong opinion of how to use rays.
Just read some articles about it. For example those two here:
The wiki is a great help. Use it.
http://www.jmonkeyengine.com/wiki/doku.php/ray
http://www.jmonkeyengine.com/wiki/doku.php/picking
Thank you for the suggestion. I just read those links, however I fear I still may be misunderstanding how to use a ray. Forgive me if I am missing something.
My idea is to cast a ray from a position on the front face of the PhysicsCar. When I get the distance results as shown in the distance example in the wiki, I would compare the shortest distance to a limit I have set for the ray. If the distance returned is smaller than the ray's limit, then the sensor would register a "hit" and I could make the car drive to avoid whatever obstacle is in the way. If the distance is further than the ray's limit then the sensor, then it must be clear in front of the vehicle (at least as far as the sensor's limit can see) and it can continue to drive straight.
Please let me know if my logic is wrong with that or if there is a better way. I plan later on having multiple sensors in multiple directions and not all of the results will be so binary. Eventually I would like to put the returned distance into a formula I have that simulates a real-world senor's output based on distance.
The problem I was having mainly was how to attach the ray to the front of the physics car so that as the car drives and turns, the ray stays in the same relation on the car. Again, later I plan on having a specific model for a "sensor" that I will load with my car, and the center of this box will be where the ray originates. I figure if I could attach it to the front of the PhysicsCar first, I could do more testing until I get a good model created.
Thanks again for your help.
Well, first to the position your ray starts:
You can easiley calculate the position where it should start by using the location of your model and the bounding boxes extends.
Your algorithm… well, its not the optimized solution, i would say. First: Rays are infinitely thin. Small objects which could be in the way but are not hit by the ray won't be recognized by the ray, so your algorithm would fail.
Well then…your idea of rays… Jme dosn't provide an finite ray. Rays are infinite. But it can order the results, so you can easiley go thorugh them and check wether there is an object in the minimum range.
Sorry for my english, i'm rly tired… 
I admit, the infinitely small ray would pose a problem. i was hoping this would be one step in figuring out my problem. I plan on simulating several types of sensors:
One type would use Rays very much like a LIDAR system, which scan a laser beam and return the distances from objects so one can create a 3D model (basic description).
Another type would use a cone shape detection area. The reason I'm not simply using a cone model, then using CollisionShapes is that I need the incremental distances here to put in a formula which simulates a real-world sensor. As far as I know, you only get a "hit" or "miss" with the collisionshape.
A third type would use an ellipsoid shaped detection area. Again, incremental distances are required.
I assumed an array of Rays would be the only way to do this. I would cast a bunch of Rays out in a cone shape, and return the closest distance returned (as long as they were all within the limits I set for max sensing distance.) though to do this correctly, I would need to do this many times concentrically around the base of the cone to reasonably fill the volume of the imaginary cone.
If there is a better or faster way of doing this, PLEASE tell me. I come from a low level programming background so I have a bad tendency to reinvent the wheel. (My background is in ASM and C but I also know Java).
I really appreciate your help and look forward to your replies!
About the base problem… How about adding a sphere ghostnode thats larger than the car, updating its position each frame to the car position and checking for collisions with the sphere?
Cheers,
Normen
It is possible to do the ultrasonic sensor simulation by using graphics hardware.
First you render a high resolution view from the cone vertex to an offscreen buffer, then you iteratively down-sample it, ignoring any pixels that are not in the cone's "circle", while running the MIN function on the inputs. The result would be a single pixel containing the minimum depth from the cone vertex. You can then read the pixel from the buffer and you have the minimum distance you want for the sensor.
Since its using the GPU, it is able to process a tremendous amount of "rays". For example, a 1000x1000 offscreen buffer is 1,000,000 pixels, running the aforementioned shader would be a relatively cheap operation, you should be able to process this at 60 Hz, or 60,000,000 rays per second.
No CPU could come close to doing that many ray casts.
About the ghost sphere again… When you got the objects that are close to the car you can do a bit of math to check what their actual location relative to the car is and then check if they are in a cone in front of the car or something. As momoko said, ray casting is way too much overhead so you will have to do things differently. The GhostNode could of course also be any of the other base shapes available in bullet. So a cylinder or something "in front of" the car would probably be closer to what you want.
You imported the wrong cylinder class in the top of your class file. Never use objects from com.bulletphysics! They will be gone when physics goes native. Import com.jme3.scene.shape.Cylinder and remove the import for com.bulletphysics.demos.applet.Cylinder 
This fixed the problem… once I figured out how to make a cylinder. I had just used the NetBeans auto importer thing.