Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / ObjectRayCast performs poorly with LoadObjectWithChildren

Author
Message
swift-au
4
Years of Service
User Offline
Joined: 13th Apr 2020
Location:
Posted: 18th May 2020 08:29 Edited at: 18th May 2020 10:41
I have some animated character models (you can test with Swat.X from FPSC "Modern Day" pack as it exhibits the same problem) and am using ObjectRayCast() from my camera x/y/z to the character model x/y/z . If I use LoadObject() the hit is detected well anywhere on the model. If I change nothing except replace LoadObject() with LoadObjectWithChildren(), the hit detection is very poor. In particular, the torso doesn't register any hits whatsoever (neither the front nor back of the torso)! The model contains bones and animation (animation is NOT being played in the test), but only one mesh and no child objects. Has anyone experienced this issue with LoadObjectWithChildren()?

Possibly it would help if I extended the ray beyond the model slightly (I'll try it later), thought since it works perfectly with LoadObject() I see no reason why LoadObjectWithChildren() should behave differently.


Looking at the Tier2 source on GitHub, it appears that AppGameKit creates bounding boxes around models with bones, which no doubt explains why the raycasting works differently. It doesn't fully explain why it appears to be so lousy

I think perhaps I'll just cast the ray in the opposite direction and see if that works out better

I note also that ObjectSphereSlide() does not appear to work at all for the model loaded with LoadObjectWithChildren(), but works fine when loaded with LoadObject().

Note that I have removed bone scaling from the model, though AppGameKit still complains that "Bone transform matrix contains scale values, scaling of bones is not supported and will be ignored". I suspect it may be due to floating point rounding issues (e.g. 1.0000001 != 1). The animations work perfectly, so I'm sure the problem is not related to this.
swift-au
4
Years of Service
User Offline
Joined: 13th Apr 2020
Location:
Posted: 19th May 2020 02:57
Ok, so I've tried casting the ray from the model to the camera, and it mostly works (occasionally a hit will be detected on the model the ray is being cast FROM). I still have a problem however if I want to register bullet hits on the character model, because when firing at the torso, more often than not the bullet will sail right through the model, undetected by the character model.

Any suggestions would be appreciated.
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 19th May 2020 07:16
Raycast will not detect back faces so if you are casting from the center of the model to the camera it will no register because all the faces on the model point outwards.
Maybe try casting from the camera to the model instead
swift-au
4
Years of Service
User Offline
Joined: 13th Apr 2020
Location:
Posted: 21st May 2020 00:33
@blink0k, I think you misunderstood me. I started out by casting from the camera to the model, but almost all hits aimed anywhere at the torso of the character model do not register as hits. I switched to casting from the model to the camera, which I can make work to detect line of sight between camera and model, however I can't use this to register bullet hits. It seems like collision testing when using LoadObjectWithChildren() is badly broken. Like I said, it works perfectly when using LoadObject()
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 21st May 2020 04:57 Edited at: 21st May 2020 04:57
It may also be that the primary mesh does not contain the torso. As an experiment try raycasting and set the objID to zero;
ObjectRayCast( objID, oldx, oldy, oldz, newx, newy, newz )
swift-au
4
Years of Service
User Offline
Joined: 13th Apr 2020
Location:
Posted: 21st May 2020 08:58
I've already checked that there is only the one mesh (GetObjectNumMeshes() == 1), and no children. Also, my bullet code already does a test on all objects, and bullets sail right through the torso, undetected. Don't get me wrong, it does detect some areas of the torso, but probably only about 20%. It looks pretty dumb to shoot the character in the chest at nearly point blank range, and have the bullet "miss" and hit the wall behind him!
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 21st May 2020 21:48
If you want to message me the model i could have a look
swift-au
4
Years of Service
User Offline
Joined: 13th Apr 2020
Location:
Posted: 22nd May 2020 01:10
Here's some sample code (slightly modified example from the documentation) using the FPSC stock model Swat.X (attached), which I think clearly demonstrates the problem. Change the LoadObjectWithChildren to LoadObject, and you'll notice it works perfectly.

Attachments

Login to view attachments
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 22nd May 2020 01:31
Turn off collision for the spheres.

Also, in your ray cast you are checking for object 1, set it to 0 to check for all objects. Swat.x has multiple meshes I think, so its technically multiple objects. I suspect what is happening is that sometimes the collision is another mesh, which might be a higher object number than 1. When you change loadobjectwithchildren to loadobject, animation is lost and AppGameKit tries to compress everything to one mesh - fairly sure I recall the help saying something like that.
swift-au
4
Years of Service
User Offline
Joined: 13th Apr 2020
Location:
Posted: 22nd May 2020 01:41 Edited at: 22nd May 2020 01:43
Quote: " Swat.x has multiple meshes I think, so its technically multiple objects"


No, it doesn't. It's a single mesh.

Collisions on the spheres and raycast checking all objects makes no difference. The example I posted demonstrates it very clearly.
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 22nd May 2020 03:53
You are correct swifty. I had a look at the model (There are children, only 1 and it is a marker poly for the gun)
I thought the polys on the model might be facing the wrong way but they look ok.
At the top of the chest the ray passes through the facing polys and registers at the back of the model.
If you use loadObject() it works perfectly.
Very odd behavior. I'm sure i've seen models like this used a lot and i haven't heard of any problems
This thread talks about a 40 bone limit but 'm not sure if that will help with your problem
swift-au
4
Years of Service
User Offline
Joined: 13th Apr 2020
Location:
Posted: 22nd May 2020 04:18 Edited at: 22nd May 2020 04:21
Quote: "I had a look at the model (There are children, only 1 and it is a marker poly for the gun)"


A child for the FIRESPOT, yes, but the model is still a single mesh. In any event, removing the FIRESPOT (ensuring there is exactly 1 mesh and 0 children) makes absolutely no difference, so I think we can rule the multiple mesh/children scenario out.

Quote: "If you use loadObject() it works perfectly."


As I mentioned before, I think it's because LoadObjectWithChildren() creates bounding boxes using the bones as a reference, so that collisions will work when the model is animated. LoadObject() of course doesn't use bones whatsoever. The irony is that collisions aren't working with LoadObjectWithChildren() even when the model ISN'T being animated!

Quote: "Very odd behavior. I'm sure i've seen models like this used a lot and i haven't heard of any problems
This thread talks about a 40 bone limit but 'm not sure if that will help with your problem"


Swat.X only contains 35 bones, so shouldn't be a problem. Plus the docs say up to 200 bones is fine on modern hardware. I can reproduce the problem on heaps of models with a similar poly count and bone structure. It seems very odd that nobody has encountered this before -- though looking at the thread you referenced, I see the OP also claimed that hit detection wasn't working properly (even after having the number of bones in the model reduced to <= 40), to which he received no further replies.

Anyway, thanks for confirming that it's not just me
swift-au
4
Years of Service
User Offline
Joined: 13th Apr 2020
Location:
Posted: 22nd May 2020 05:16 Edited at: 22nd May 2020 06:16
Ok, I've attached an image that shows the bounding boxes AppGameKit creates for the Swat.X model, when loaded with LoadObjectWithChildren(). The yellow parts are the bounding boxes, and the semi-transparent blue sections are areas not covered by the bounding boxes, and therefore will not be detected by ray casts. I hope this can be fixed.

Attachments

Login to view attachments
swift-au
4
Years of Service
User Offline
Joined: 13th Apr 2020
Location:
Posted: 22nd May 2020 06:14 Edited at: 22nd May 2020 06:15
Digging a little further, the attached I think clearly illustrates why AppGameKit doesn't correctly create all bounding boxes for the Swat.X model. In cases where a bone only influences a small number of vertices (and those vertices may only create a 2D plane), AppGameKit doesn't know how to draw the 3D box. It would have to take into account vertices of neighbouring bones (and even this may not work 100% of the time).

Anyway, at least now that I know why it doesn't work, I can probably adjust my models accordingly and work around it.

Attachments

Login to view attachments
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 22nd May 2020 07:30
Yes. The soldier in the AppGameKit examples works fine

Attachments

Login to view attachments
swift-au
4
Years of Service
User Offline
Joined: 13th Apr 2020
Location:
Posted: 22nd May 2020 08:46
Quote: "Yes. The soldier in the AppGameKit examples works fine"


Sure, but AppGameKit is a generic library designed to work with more than the one character model it ships with, isn't it? And nobody can say that the Swat.X (and similar) model is "faulty", because it's not. The fact is that we have a situation where a single bounding box around the entire model would work better than the bone based bounding boxes in many instances (ignoring of course the case where the animations may cause parts of the model to move outside the static bounding box). Hopefully this can be addressed in a future release, as it would be far better to test too many polygons and waste a few CPU cycles, as opposed to not test enough and miss a large number of valid hits.

Login to post a reply

Server time is: 2024-04-19 04:41:17
Your offset time is: 2024-04-19 04:41:17