I'm looking at collisions more closely, and I've found that PAL gives different results depending on the underlying engine used, due to different engines doing "skin width" (a.k.a. "collision margin") differently. For example, PhysX/Novodex has a default of 0.025. Bullet's default is 0.04, except that it auto-adjusts geometry of some object types but not others. ODE doesn't have one, as far as I can tell.
I think it would be a good idea if PAL had a settable default that it enforced on objects it created, at least where possible. For example, we might pick a default of 0.03 and then the Bullet and Novodex interfaces would set that when an object is created.
I'm not proposing getting rid of the skin width methods in palBodyBase, just that we have the concept of a default skin width so users don't have to set it on every Body they create just to get consistent results across physics engines.
I was thinking of adding getDefaultSkinWidth and setDefaultSkinWidth methods to palPhysics to provide control over the default.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem I was running into was that bullet actually has two skin widths. It has margin on the shapes, and the contact processing threshold on the body, which do different things.
I just added the skin width method to the body base so it can be set.
Now, if you are going to set a default skin width, you'll have to make sure that propagates in the pal code to the bodies that get created, that is, you could probably implement it just fine entirely in the pal interface without modifying code. On physx, the skin width is just on the geometry.
That sort of tells me that maybe the skin width getter/setter should be put on the palGeometry object, not the body, but then you can't set the contact processing threshold in bullet.
Additionally, in bullet, the margin is not something you want to go mucking with, AND it behave differently on different shapes. That is, from the bullet manual, a sphere is entirely implemented as margin. Also, a capsule size is essentially expanded by the margin while a box subtracts the margin from the size to help with that same problem. We could work around that and make it consistent with bullet, but it they may change that behavior from version to version and it would be hard test.
Either way, it's probably not possible to get EXACTLY the same behavior an multiple engines, and I'm not sure that should even be the goal of pal. We want to get as close to the same behavior as possible without doing anything crazy because we also want a straightforward implementation, I would think. That will make the jobs of the developers using it easier since I would guess that most of them well end up picking an engine to use on the final project.
As an additional note, you may want to make the default a named property. That is, you may want to add it to the generic string properties you can send into the physics interface.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem I was running into was that bullet actually has two skin widths. It has margin on the shapes, and the contact processing threshold on the body, which do different things.
I found the margin for the shapes. I hadn't seen the contact processing threshold before.
I just added the skin width method to the body base so it can be set.
Sounds good.
Now, if you are going to set a default skin width, you'll have to make sure that propagates in the pal code to the bodies that get created, that is, you could probably implement it just fine entirely in the pal interface without modifying code. On physx, the skin width is just on the geometry.
Well, I could change the contact processing threshold from the current pal interface, but not the margin. I realize that there are potential gotchas to making the margin too small, but I may need control over it nevertheless.
That sort of tells me that maybe the skin width getter/setter should be put on the palGeometry object, not the body, but then you can't set the contact processing threshold in bullet.
Good point. I guess we may want some kind of threshold/margin type of property for both geometry and bodies. Kinda messy.
Additionally, in bullet, the margin is not something you want to go mucking with, AND it behave differently on different shapes. That is, from the bullet manual, a sphere is entirely implemented as margin. Also, a capsule size is essentially expanded by the margin while a box subtracts the margin from the size to help with that same problem. We could work around that and make it consistent with bullet, but it they may change that behavior from version to version and it would be hard test.
Yeah, the margin in Bullet is hairy. Actually, it was the differing behavior on different kind of shapes that made me think pal ought to do something to make this all more uniform. That's just icky. Some code somewhere is going to have to know that Bullet treats different shapes differently w.r.t. the margin. It makes sense to me for that code to be in pal rather than in every app that uses pal (with Bullet).
Either way, it's probably not possible to get EXACTLY the same behavior an multiple engines, and I'm not sure that should even be the goal of pal. We want to get as close to the same behavior as possible without doing anything crazy because we also want a straightforward implementation, I would think. That will make the jobs of the developers using it easier since I would guess that most of them well end up picking an engine to use on the final project.
You make a good point that there's a cost to making pal exactly the same for various engines (and it's probably not always even possible). I agree that that's not necessarily the goal. For our application, we may choose to target a single engine eventually, but our whole motive for using pal in the first place was so we wouldn't have to pick just one. So I'm inclined to push the collision stuff closer to uniformity than it is now, at least for the two engines we care about (Bullet and PhysX). Even though I see that it's more complicated than I had thought.
As an additional note, you may want to make the default a named property. That is, you may want to add it to the generic string properties you can send into the physics interface.
Sounds good to me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm looking at collisions more closely, and I've found that PAL gives different results depending on the underlying engine used, due to different engines doing "skin width" (a.k.a. "collision margin") differently. For example, PhysX/Novodex has a default of 0.025. Bullet's default is 0.04, except that it auto-adjusts geometry of some object types but not others. ODE doesn't have one, as far as I can tell.
I think it would be a good idea if PAL had a settable default that it enforced on objects it created, at least where possible. For example, we might pick a default of 0.03 and then the Bullet and Novodex interfaces would set that when an object is created.
I'm not proposing getting rid of the skin width methods in palBodyBase, just that we have the concept of a default skin width so users don't have to set it on every Body they create just to get consistent results across physics engines.
I was thinking of adding getDefaultSkinWidth and setDefaultSkinWidth methods to palPhysics to provide control over the default.
The problem I was running into was that bullet actually has two skin widths. It has margin on the shapes, and the contact processing threshold on the body, which do different things.
I just added the skin width method to the body base so it can be set.
Now, if you are going to set a default skin width, you'll have to make sure that propagates in the pal code to the bodies that get created, that is, you could probably implement it just fine entirely in the pal interface without modifying code. On physx, the skin width is just on the geometry.
That sort of tells me that maybe the skin width getter/setter should be put on the palGeometry object, not the body, but then you can't set the contact processing threshold in bullet.
Additionally, in bullet, the margin is not something you want to go mucking with, AND it behave differently on different shapes. That is, from the bullet manual, a sphere is entirely implemented as margin. Also, a capsule size is essentially expanded by the margin while a box subtracts the margin from the size to help with that same problem. We could work around that and make it consistent with bullet, but it they may change that behavior from version to version and it would be hard test.
Either way, it's probably not possible to get EXACTLY the same behavior an multiple engines, and I'm not sure that should even be the goal of pal. We want to get as close to the same behavior as possible without doing anything crazy because we also want a straightforward implementation, I would think. That will make the jobs of the developers using it easier since I would guess that most of them well end up picking an engine to use on the final project.
As an additional note, you may want to make the default a named property. That is, you may want to add it to the generic string properties you can send into the physics interface.
Thanks for the detailed reply.
I found the margin for the shapes. I hadn't seen the contact processing threshold before.
Sounds good.
Well, I could change the contact processing threshold from the current pal interface, but not the margin. I realize that there are potential gotchas to making the margin too small, but I may need control over it nevertheless.
Good point. I guess we may want some kind of threshold/margin type of property for both geometry and bodies. Kinda messy.
Yeah, the margin in Bullet is hairy. Actually, it was the differing behavior on different kind of shapes that made me think pal ought to do something to make this all more uniform. That's just icky. Some code somewhere is going to have to know that Bullet treats different shapes differently w.r.t. the margin. It makes sense to me for that code to be in pal rather than in every app that uses pal (with Bullet).
You make a good point that there's a cost to making pal exactly the same for various engines (and it's probably not always even possible). I agree that that's not necessarily the goal. For our application, we may choose to target a single engine eventually, but our whole motive for using pal in the first place was so we wouldn't have to pick just one. So I'm inclined to push the collision stuff closer to uniformity than it is now, at least for the two engines we care about (Bullet and PhysX). Even though I see that it's more complicated than I had thought.
Sounds good to me.