I’ve put a ray sensor into a game engine project. TRUE pulses are routed to a Python script. When I read getHitPosition(), I get the same location as getPosition() returns for the owning object, i.e. a hit at zero range. I’ve tried both a Mesh and and Empty as the owning object,with the same results. I’m using the sensor looking in the +Y direction, because there’s an old bug report that says only Y works.
I’ve tried moving the Empty clear of any object. Doesn’t help. I’ve tried setting the sensor range to a small value. It still fires. So it seems to be detecting something at zero range. But there’s nothing there.
It’s not volumetric, but it also doesn’t care about normals. So it will hit the backside of faces as well as the front. This could be the problem. I think the old +y bug went away. Keep testing it I haven’t played with this function in a while, it may have issues in 2.34?
The sensor is in open space, set to only report collisions with property “Ground”. The thing it’s attached to is an Empty, and doesn’t have property “Ground”. And, from looking at the code, a ray sensor doesn’t see its own object, anyway. Yet it clearly is reporting a hit at a range of zero. That shouldn’t be happening.
I’ll do some testing in a simpler scene.
(As for what I’m doing, I’m building a robot simulator for a DARPA Grand Challenge vehicle (www.overbot.com), starting from the 55wheels demo in the game kit. I’m trying to simulate a laser rangefinder with the RaySensor. So I really need this to work.)
The ray sensor works in a simple scene. It works in a scene with a complex mesh appended from the scene that doesn’t work. It doesn’t work right in a modified version of 55wheels.blend, but reports hits at the origin of the RaySensor, at zero range.
One of the ray sensors used to control the wheels in 55wheels.blend doesn’t seem to work quite right, either. Load that game up from the GameKit and look at how the rear wheels behave. You may have to use a front view and wireframe to see this.
I’m starting to think it’s a collision detection bug.
OK. Now I know what’s happening, but I don’t know why.
In the scene “55wheels.blend” from the GameKit, there’s a moving car. It has an object “Car”, which, in wireframe, is drawn as an axis with an enclosing dotted circle in all views.
Inside that circle, a RaySensor will report a collision at range 0 on every cycle. Outside that circle, a RaySensor works normally.
Why? And what does an enclosing dotted circle mean? Thanks.
55wheels.blend uses a “dynamics model” which consists of an empty with a spherical collision detection region. This interferes with any ray sensor within it, including the one in 55wheels which controls the drop of the rear wheels. That’s why, in the game as it comes with the GameKit, the rear wheels don’t touch the ground. (They’re not dynamic objects; they’re managed by a RaySensor that senses the property “Ground”) I’ve been able to fix that
by making the sphere associated with the empty smaller. As soon as the RaySensor which controls RearDrop is outside of the sphere, it works right.
There seems to be a Blender bug in that RaySensor will trigger when inside collision objects which don’t have the requested “property”.
Is this a holdover from pre-Sumo collision handling, or what? Where is the current documentation on collision detection? The descriptions I’ve read don’t match this behavior.
The ray sensor detects a collision on the FIRST face it sees in front of it. It has always been this way. Now, it shouldn’t be reporting TRUE if the thing it sees doesn’t match your property, but it wont be able to see anything past that either.
In 2.25 and prior, it would not see the inside of bounding shapes (in that case spheres only) but in 2.34 it does have this problem I believe. So you’ll have to place it on the edge of the sphere.
It would be nice to have a ray that keeps going until it hits something with the propery you put. Kester?
The ray sensor detects a collision on the FIRST face it sees in front of it. It has always been this way. Now, it shouldn’t be reporting TRUE if the thing it sees doesn’t match your property, but it wont be able to see anything past that either.
OK. That makes sense.
It’s reporting a hit exactly at the RaySenoor location, even though there’s no face at tha location to collide with. It’s just inside a bounding sphere. So it looks like there are volumetric collisions for bounding spheres. Which makes sense. Bounding sphere collision detection is usually volumetric, since that’s easy to do.
If you look at the code for KX_RaySensor.cpp in the latest CVS revision, it’s trying to ignore objects that don’t have the right property. It will keep looing aoong the direction of search if it gets a false hit on 1) the same object that has the ray sensor, or 2) an object with a type > ACTOR, whatever that means. I don’t see how you can get a hit return from that code on something with the wrong property. It seems to be happening, though.
I’d also suggest taking a good look at the fix to bug 1126 in revision 1.5 while thinking about the implications of volumetric collisions.
(Exactly what does the current collision engine understand, anyway? I know you have Gino’s SOLID in there, and I understand what that does, but I’m not clear on how Blender maps its primitives to SOLID primitives.)
Always make sure the ray sensor is positive before trying getHitPosition(). If the ray sensor isn’t positive, (either doesn’t hit something, or is blocked by an object without the property it’s looking for,) getHitPosition() will return an incorrect value.
It’s a good idea to always use isPositive() for any sensor before trying to get information from it, since almost all the sensors return very odd values if they aren’t positive.