Entity Pick Mode and Animations
Blitz3D Forums/Blitz3D Programming/Entity Pick Mode and Animations
| ||
| Okay here is the deal. I have a mesh that is animated. I set its pick mode to polygon. When the mesh is animated, only the area that the first frame of the animation was, will actually raise the 'pick' event, and return an entity handle. So how do i overcome this issue if i want to be able to select a mesh if lets say, frame 1 is the character standing, and frame 20 is them lying on the ground? |
| ||
| Im only ghuessing, but maybe re-setting the Pickmode for each animation frame? |
| ||
| Hm, this is an interesting problem. I assume you are referring to a skeletal animated model. For a variety of functions only the first frame registers because Blitz does not keep track of vertex deformations except immediately before rendering. Maybe you need to use a proxy object (set invisible with EntityAlpha) for detecting picks while lying down. |
| ||
| True. and a valid ideas. Thanks guys. UNfortunately im still in the same boat. Im just glad my game isnt relying heavily on heavy mesh animations. |
| ||
| Any solutions to this? |
| ||
| Maybe you can create cubes or cylinders with a shape similar to the body parts of your character, and attach the cubes/cylinders to the joints of your skeleton. When you want to use linepick, you show the meshes, when you don't want to use linepick, you hide the meshes. I think this should work, this is not really precise but it will be more precise than a random pose of an animation. |
| ||
| Yeahh, thats a good way to hack it though I was looking for something a little more proper |
| ||
| That is the "proper" way - separating your concerns across different systems. There is simply no reason to use the rendered mesh for pick detection. Using the same data for rendering and collision/picking is much more "hackish", and even if there was an obvious way to do it (besides creating your own vertex animation system, which is certainly possible but kinda overkill), it would necessarily be slower and less useful, because it has to process all the fine rendered details that you simply don't need or want for collision detection. |
| ||
| Right, Initially it seems like a limitation, something that should be handled but I understand why its not |
| ||
| Seconding the suggestion put forth in this thread. The only reason such a suggestion should be "improper" is if you used an obscene number of primitives for the picking, or if they had a ridiculous number of polygons. Basically, it's just a simple "hitbox" principle, and even Valve uses a system like this for similar scenarios such as multiplayer shooting. |
| ||
I never had this issue and I have worked with a lot of animated models. I always did it like this (from memory):
Type model
Field mesh
Field picked
End Type
m.model = New model
m\mesh = LoadAnimMesh blah blah
EntityPickMode m\mesh,2
While Not KeyDown(1) ;Main Loop
If MouseHit(1) = True
pick = CameraPick(MouseX(),MouseY())
For m.model = Each model
If m\mesh = PickedEntity()
m\picked = True
Else
m\picked = False
EndIf
Next
EndIf
For m.model = Each model
If m\picked = True
;Do Stuff
Endif
Next
Wend
End
|
| ||
| The problem is the polygon detection is only from the first frame of animation. If you had something that move position within the animation frames, you will still be detecting the polgyons positions from the first frame. And this only applies to .b3d boned animations. And hopefully I will be back on track and email you tonight! |
   |