I was wondering what the difference was between a game object’s normal and it’s vector. I’m trying to line up a bullet hole with an object and I’m trying to not use rays, because the bullet is really big (though I think I got the ray to work anyway). I was just curious.
A Normal is a Vector, representing the direction of a surface. In mathematics, a normal is simply the tangent to a curve.
The “vector” of a GameObject isn’t really defined. Perhaps you mean its position vector? There are also Angular velocity vectors and velocity vectors. A Vector itself is just a means of expressing a displacement in 3D space, although they are used for other things too.
The actual definition of a vector is a scalar value with additional information giving the value another dimension.
Ok, so is there a way to get the normal value without using a ray?
hit position on collision? no…
not yet at least?
There is no normal for an object, but to get the normal of a face, a ray is often the easiest method, it all depends.
So what is the bigger picture?
A vector: describes a direction and a length within a defined space (e.g.: 3D space = XYZ, Texture space = UV)
A normal vector (n):
- is a vector
- is always related to at least one other vector (b) [there can be more (b0), (b1)]
- is orthogonal to the related vectors [means there is a 90° angle between them]
- has a length of 1.0 (= normalized
)
Wait! related to another vector? I have a face not another vector.
That is right. But what is a face: it is a plane bordered by three lines. How is a plane described? There are several methods (three points, or one point and two vectors). Here we go, one point and two vectors -> a normal of a plane relates to the two vectors (the point does not matter). Be aware a plane is always flat ;).
What agoose77 already said, belongs to faces too: “A Normal is a Vector, representing the direction of a surface.”
A normal to a curve (at a given point) is a line perpendicular to the tangent: http://en.wikipedia.org/wiki/Normal_vector
The actual definition of a vector is a scalar value with additional information giving the value another dimension.
A scalar value is nothing more than a one-dimensional quantity - a real number. The multidimensional aspect stems from the fact that vectors are composed of multiple scalar values, not from information added to a single scalar value.
In other words: A vector is not a scalar value with some additional information; It is a collection of scalar values which encode magnitude and direction.
How is the size of the bullet relevant? Why is using rays problematic in this case?
Oh, man, typo.
Concerning the definition, yes, that’s essentially the point - You can consider the two as a difference in dimensions.
That’s not the point you made. You stated that a vector is a scalar value, which is fundamentally incorrect.
Regarding your new point (the two as a difference in dimensions): That is also incorrect, because it implies that a scalar is conceptually identical to a vector, which is clearly not true.
It would be like comparing an integer to an array of integers, and stating: “You can consider the two as a difference in length”.
Once again, clarifications.
I attempted to clarify the meaning behind my original statement. A one dimensional vector is equal to a scalar. The very notion of which is used to explain how information is reduced between successive lower dimensions. It also explains some of the concepts outlined in FlatLand, a good read for any who have not.
It would be like comparing an integer to an array of integers, and stating: “You can consider the two as a difference in length”.
A difference in dimensions, in terms of mathematics, would be supported by this previous statement.
Back to the subject at hand, I assume by bringing up the size of the bullet he means a ray is impractical because a ray has no volume, and so a large bullet could clip past corners if the ray misses but the bulk of the bullet still passes through, or the bullet could travel through holes that are much too small for it to fit through if it had a physics representation rather than a ray (whereas in most games, bullets are small enough that their volume is negligible so a ray is a perfectly fine approximation).
Unfortunately, I can’t think of any good solutions… perhaps the best option is to shoot a few rays all in the same direction (say, five- one in the center, and four off of corners of the bullet) almost like antialiased sampling in raytracing, in the attempt to approximate the volume of the bullet. Then if one of the rays hits something treat it like a collision (if more than one ray hits in a frame, just use the closest hit position) and you can add a bullet hole using the hit normal, or do a ricochet or whatever you want to do. It’s not a very clean or efficient solution, but I think it might be the best option available. You can improve the quality by increasing the number of “samples” (IE rays) at the cost of performance.
If it’s not already enabled, it might be worth investigating CCD for a collision sensor-based approach (API: setCcdMode, bge.constraints)
Wow, I may need to take some time off work to figure all this out.
The game has a bunch of ducks moving in a row that you shoot with a gun that fires eggs (don’t ask). The eggs are relatively large, that’s why I didn’t think a ray to get the normal value would work, however, it seems like it is. When I use the ray to get the normal and line up the bullet hole (egg yolk, whatever) it works perfectly fine, though I don’t think the ray is hitting it every time. So now I’m wondering why is this working right?
For us to tell why it’s working correctly, it’d be helpful to provide the blend file or the script you’re using. The egg’s raycast function should always work correctly, so it’s probably your arguments if the object isn’t always detecting a hit. Are you adding the speed of the egg (egg.worldLinearVelocity) divided by the logic tick rate (logic.getLogicTicRate()) into the distance (or the “To”) property of the function? Basically, you want to cast a ray forward to where the egg will be, rather than where it is, or just ahead of where it is.
Note that this could be a bit unnecesary depending on how you want to approach things, though; if the eggs are large enough and move slowly enough, you could just rely on a standard collision sensor. For where the egg yolk would be when the egg “explodes”, you could just set the yolk’s position to be the duck’s position and a bit backward on the Y axis (I’m imagining a shooting gallery, where the ducks are facing the camera, which is looking down +Y, as usual). I’d use raycasts if you need to have small, fast-moving objects, or if you need the hit position of where it strikes.
Anyway, you’d know best what you need.
I think the main problem is that the splatter looks like it is partly hanging in air.
Unfortunately there is not simple solution unless you ensure the possible hit points are all quite flat with enough space around.
A simple trick is, the little ducks disappear when hit = no splatter at all. The wall behind the dugs is already flat = no problem. The area in front and below the dugs might be a problem because of the edges. You could get around that with a slope. This way the splatter will always hit a flat surface.
If you can handle it a bit more complicated, you can divide the splatter into several parts. Each part looks for it’s own surface to glue on. As the parts are smaller than the complete splatter, the “hanging effect” is not that obvious.
You could even use softbodies as splatter. I guess this will have it’s own issues.