Search found 4546 matches
- Tue Jul 21, 2009 5:40 pm
- Forum: Suggestions
- Topic: Multiple collisiongroup per entity
- Replies: 10
- Views: 15066
Re: Multiple collisiongroup per entity
By the way, if you're using noResponse as a CollisionRule between trigger entities and other entities, the cost associated with doing the collision check to generate contacts is generally orders of magnitude greater than the event processing. For range checking in particular, your best bet would be ...
- Tue Jul 21, 2009 5:14 pm
- Forum: Suggestions
- Topic: Multiple collisiongroup per entity
- Replies: 10
- Views: 15066
Re: Multiple collisiongroup per entity
If you re-use the same dictionary/collisionRules instance across a variety of entities, you will have to do very few operations (amounting to nanoseconds) when things are created or destroyed. However, it may end up being more complicated overall for your specific situation than doing it another way...
- Tue Jul 21, 2009 3:12 pm
- Forum: Questions and Help
- Topic: Which physics object for a robot?
- Replies: 1
- Views: 3309
Re: Which physics object for a robot?
The ideal solution for building a robot would be the modules connected by constraints. The constraints would keep the robot together, serve as motors when needed, and possibly supply friction. Unfortunately, BEPUphysics does not have explicit support for all the constraints necessary in v0.10.0. v0....
- Mon Jul 20, 2009 7:18 pm
- Forum: Suggestions
- Topic: Multiple collisiongroup per entity
- Replies: 10
- Views: 15066
Re: Multiple collisiongroup per entity
I can see how it could become problematic if you did have a group for every entity, but I don't think I understand why you need a group for every entity. It sounds like the specificEntities list might help out a bit. You could add a bunch of entities to an entity's collisionRules' specificEntities l...
- Mon Jul 20, 2009 2:21 pm
- Forum: Suggestions
- Topic: Multiple collisiongroup per entity
- Replies: 10
- Views: 15066
Re: Multiple collisiongroup per entity
While I may do something like this, you can accomplish what you want to do by creating a collision group that represents the combination of the two other CollisionGroups. Basically, if you give an entity multiple CollisionGroups, the final rule will be equivalent to using a single collision group wi...
- Sat Jul 18, 2009 7:49 pm
- Forum: Questions and Help
- Topic: 0.10.0 CollisionPair should be default to noPair
- Replies: 5
- Views: 4961
Re: 0.10.0 CollisionPair should be default to noPair
To clarify, no, you do not need both a relationship between group A and group B and between group B and group A. The two orderings are considered equal as far as the equality comparer and hash code are considered, so a rule between two groups can be thought of as 'two way.'
- Fri Jul 17, 2009 11:11 pm
- Forum: Questions and Help
- Topic: 0.10.0 CollisionPair should be default to noPair
- Replies: 5
- Views: 4961
Re: 0.10.0 CollisionPair should be default to noPair
CollisionGroups were not designed primarily to prevent collision between groups of entities, but rather as a more general way to manage interactions. That's why it defaults to normal if no other rule is specified. For every simulation that would benefit from having group relationships default to noP...
- Fri Jul 17, 2009 1:48 pm
- Forum: Questions and Help
- Topic: Switching to dynamic falls through terrain 0.10.0
- Replies: 1
- Views: 3173
Re: Switching to dynamic falls through terrain 0.10.0
By default, becomeDynamic/becomeKinematic do not change the collisionGroup of the entity. They have a secondary overload that lets you pass a collision group, or you can set it afterward. The reason the object falls through the terrain is because it still has the defaultKinematicCollisionGroup from ...
- Fri Jul 17, 2009 1:55 am
- Forum: General
- Topic: BEPUphysics v0.10.0 is now available!
- Replies: 0
- Views: 32387
BEPUphysics v0.10.0 is now available!
If you haven't checked the main page, BEPUphysics v0.10.0 is ready!
Check it out at http://www.bepuphysics.com.
Check it out at http://www.bepuphysics.com.
- Thu Jul 16, 2009 10:11 pm
- Forum: Suggestions
- Topic: EventHandlerCollisionOnStay
- Replies: 1
- Views: 4447
Re: EventHandlerCollisionOnStay
Quick update; this is implemented in v0.10.0 as EventHandlerCollisionPairUpdating, EventHandlerCollisionPairColliding, and their "immediate" versions. The updating event occurs every single time that a collision pair associated with the entity with the event hook has its contact manifold u...
- Thu Jul 16, 2009 6:59 pm
- Forum: Questions and Help
- Topic: Head Shot
- Replies: 5
- Views: 4950
Re: Head Shot
There is an overload of the Space.rayCast method that returns every hit along the ray up to a maximum distance. Using it will allow the ray to continue.
- Thu Jul 16, 2009 6:50 pm
- Forum: Questions and Help
- Topic: Head Shot
- Replies: 5
- Views: 4950
Re: Head Shot
After the initial detection, you could also just raycast some other structure, like your own mesh representation.
- Thu Jul 16, 2009 6:48 pm
- Forum: Questions and Help
- Topic: Head Shot
- Replies: 5
- Views: 4950
Re: Head Shot
You could use an outer shape (such as the capsule itself) that fully contains the player's limbs, head and torso to detect the initial raycast. Then, test against a separate set of 'body' entities. You'd need to set up some shapes that represent the character's body (or at least the shootable parts)...
- Mon Jul 13, 2009 11:49 pm
- Forum: Questions and Help
- Topic: colliderA is sender always?
- Replies: 2
- Views: 3580
Re: colliderA is sender always?
Turns out it made it into v0.10.0.
Relevant events now also have an "other" entity parameter which is whichever collider that isn't the sender.
Relevant events now also have an "other" entity parameter which is whichever collider that isn't the sender.
- Mon Jul 13, 2009 4:48 pm
- Forum: Questions and Help
- Topic: XNA 3.1
- Replies: 26
- Views: 18100
Re: XNA 3.1
I'm aiming to have it out in the next few days. I'm on track so far, assuming I don't hit any showstopping bugs.