Why doesn't pickinfo.normal return -1, 0, or 1 only?

[CrazyM]

Forgive me if this is a silly question, but my previous experience with collision normals is as follows:

 

collision on X should return Vec3(1,0,0)

collision on -X should return Vec3(-1,0,0)

collision on Y should return Vec3(0,1,0)

collision on -Y should return Vec3(0,-1,0)

collision on Z should return Vec3(0,0,1)

collision on -Z should return Vec3(0,0,-1)

 

Leadwerks pickinfo.normal returns a fraction depending on where on a face the collision occurs. Is pickinfo.face the "normal" function I'm used to, and maybe pickinfo.normal is describing the hit point?

 

If this is the case, how do you use pickinfo.face, I couldn't find much documentation on it?

 

Thanks!

[AggrorJorn]

I haven't tested it myself but with face I assume the actual Face is being returned, which has nothing to do with the normal vector.

 

Those fractioned normal values seem correct actually. it could be that they are returned in world coordinates instead of local.

[CrazyM]

Your right, they are correct, it looks like the pickinfo.normal is describing the exact hit position, which is great for adding an impact particle effect at the location a hit occurs, though I wish pickinfo also had a separate return value that simply described the side of the hit. Good for geometric shape placement

 

pickinfo.entity:GetPosition() + pickinfo.normal = exact hit position

[Rick]

Wouldn't pickinfo.position be the actual position of the exact hit and not the normal? The normal should be the direction the face is pointing shouldn't it? You are saying it's not?

[AggrorJorn]

I agree with Rick. There are 3 vectors that you can use:

• pickinfo:Entity:GetPosition(): the actual entities pivot position. For models this is often at the bottom of the model for instance.
  
• pinkinfo.position: the actual point where the raycast hits something.
  
• Pickinfo.normal: the direction perpendicular on the face that the raycast has hit
  

See the image below:

[CrazyM]

This is what I'm getting when camera picking the X face of a cube placed on the ground.

 

if (self.player.script.camera:Pick(mousePos.x, mousePos.y, pickinfo, pickradius, true)) then
   System:Print("Entity: " .. pickinfo.entity:GetPosition():ToString())
   System:Print("Position: " .. pickinfo.position:ToString())
   System:Print("Normal: " .. pickinfo.normal:ToString())
end

 

 

Entity: -3.000000, 1.000000, 0.000000

Position: -2.555588, 1.315765, -0.250583

Normal: 0.740685, 0.526274, -0.417638

[CrazyM]

Okay, I made a much simpler script to try to eliminate any other potential causes. It's still not returning clean -1, 0, 1 values, but rather fractions.

 

Script.player = nil --entity "Player"
Script.reticle = "" --path "Reticle" "Tex file (*.tex):tex;"
window = Window:GetCurrent()
world = World:GetCurrent()
context = Context:GetCurrent()
pickradius = 0.1
pickinfo = nil
mousePos = nil
reticleOptic = nil
function Script:Start()
   pickinfo = PickInfo()
   reticleOptic = Texture:Load(self.reticle)
end
function Script:UpdateWorld()
   mousePos = window:GetMousePosition()
   if (self.player.script.camera:Pick(mousePos.x, mousePos.y, pickinfo, pickradius, true)) then
    if pickinfo ~= nil then
	    if pickinfo.entity:GetKeyValue("name") == "Block" then
		    --System:Print("Entity: " .. pickinfo.entity:GetPosition():ToString())
		    --System:Print("Position: " .. pickinfo.position:ToString())
		    System:Print("Normal: " .. pickinfo.normal:ToString())
	    end
    end
   end
end
function Script:PostRender(context)
   if reticleOptic ~= nil then
    context:SetColor(1,1,1,1)
    context:SetBlendMode(Blend.Alpha)	   
    context:DrawImage(reticleOptic, context:GetWidth()/2-32, context:GetHeight()/2-32, 64, 64)
    context:SetBlendMode(Blend.Solid)
   end   
end

 

Normal: -0.968764, -0.175351, 0.175352

[Rick]

It's fairly close (wouldn't z be 0 and not 1 in what you are expecting since the normal would be pointing directly left or right pending on the side you click?). The rotation of the object is exactly 0,0,0 both in LE and the original modeling program? Is this a model or csg? If model try this with csg.

[macklebee]

the normal will only come back as -1/0/1 if the face is aligned with a global axis

[CrazyM]

In the example output above, the pick was from the -X side, it should have returned (-1,0,0). My test is using a grid aligned cube created in blender, it has a (0,0,0) rotation in the Leadwerks map. The problem does not exist when using a CSG, I am only able to create the problem with the Blender cube import. Interestingly, good values are returned from most of the face surface area from any face, but each face has a seemingly random spot that returns bad values. I have tried a default blender cube, which is off grid by default, with a center origin, a grid aligned blender cube with a center origin, and a grid aligned blender cube with a corner origin, they all produce the same result. I have no idea how a six sided cube can return different normal values from different areas of the same face.

[macklebee]

I wonder if there are some inconsistencies on the faces due to smoothing or some feature being used when exported. I don't have blender to try but if I get a chance I will try it using a cube from another modeling app.

[DerRidda]

Did you export that cube with the official exporter plugin?

[CrazyM]

The cube is using the default flat shading in Blender. I'm using Blender 2.71 and the latest official Leadwerks exporter from github.

[DerRidda]

That exporter has some issues with rotation and positioning at the moment, try exporting to fbx instead. https://github.com/alrusdi/leadwerks-blender-exporter/issues/1

[CrazyM]

Same issue with a Blender FBX 6.1 ASCII export. Leadwerks doesn't seem to like the Blender FBX 7.5 binary export.

[DerRidda]

Have you removed your old .mdl file before importing the fbx? If it is named the same there could be naming conflicts with the resulting .mdl from the .fbx and your old one which you directly exported to .mdl via Blender.

[CrazyM]

Yes, I deleted the import file and the resultant mdl and meta files before importing the new file.

[macklebee]

It must be something with blender - either via a setting when exporting or the exporter itself. When I created boxes using UU3D and exported as mdl, fbx binary, and fbx ascii, I am able to get the expected response for normals when the model is aligned to a global axis.

testboxes.zip

[CrazyM]

Thanks for posting that example test cubes. What I've discovered is that the bad normal values are only being returned on prefabs that are instantiated into the scene at runtime. If I place the block in the scene at design time, the normals are correct. I am setting the rotation to (0,0,0) on instantiation, but still getting the bad values. After trying your cubes, I tried my Blender cubes again and found the same thing, the Blender cube works fine when placed in the scene at design time, but not at runtime.

[CrazyM]

Thanks for everyones assistance, Macklebee discovered my error, I had SetPickMode to Sphere where it should have been using Polygon. Macklebee, much appreciated. There is no issue with the Blender cube or Blender exporter for this purpose.