Jump to content

Recommended Posts

Posted

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!

Posted

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.

Posted

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

Posted

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?

Posted

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

  • Upvote 7
Posted

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

Posted

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

Posted

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.

Posted

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.

Posted

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.

Win7 64bit / Intel i7-2600 CPU @ 3.9 GHz / 16 GB DDR3 / NVIDIA GeForce GTX 590

LE / 3DWS / BMX / Hexagon

macklebee's channel

Posted

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.

Posted

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

Win7 64bit / Intel i7-2600 CPU @ 3.9 GHz / 16 GB DDR3 / NVIDIA GeForce GTX 590

LE / 3DWS / BMX / Hexagon

macklebee's channel

Posted

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.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

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...