Jump to content
CrazyM

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

Recommended Posts

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!

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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?

Share this post


Link to post

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:

post-45-0-44981700-1409328466_thumb.jpg

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...