Constraints remove when involved entity is removed?

[Socram]

Quick question today, when you create a constraint, for example between entA and entB, and then you remove entA from the space, does the constraint still exist in the space? Or does it need to be removed manually?

[Norbo]

The constraint does indeed still exist in the space after a connected entity is removed. If you want the constraint removed, you'll have to do it manually.

[Socram]

Okay thanks, very good to know. Now I have another more general programming question, that definitely goes beyond the scope of the library but you seem really good at figuring out these kinds of issues so maybe you can help. Feel free to ignore this since it is pretty much completely irrelevant to the library:

As you can see in the image below my current project consists of a block based vehicle building system. Certain Blocks can only attach to other blocks on specific sides, shown with the horribly drawn green arrows. I'm having a difficult time thinking of a way to easily track and check if two valid sides are touching, especially since all the parts can be rotated in any direction (at 90 degree increments).

Can you think of an easy way to track valid sides and easily check when a block can be placed (a wheel under a regular block), and when it can not (a regular block below a wheel). Thanks for your time, I hope this makes sense.

[Norbo]

If there's a 'real' grid structure in which all the pieces are stored (which looks to be the case judging by the videos), then it can be done pretty simply. Each piece would have a set of directions that represent the attachable faces. For a regular box, this would be the box's local up, down, left, right, forward, and backward. For a wheel, it would be only up.

Those directions would be based on the current OrientationMatrix's up, down, left, right, forward, and backward vectors, so you don't have to worry about doing more transformation work.

To determine if a block can attach, you could do something like this pseudocode:

Code: Select all

bool CanAttach(attachingBlock, attachCellX, attachCellY)
{

foreach (direction in which the attachingBlock can attach)
{
     int adjacentCellX, adjacentCellY;
     //Computes the location of the adjacent grid cell based on the current block grid position and the direction.
     //The direction will already have very nearly integral values, so put them into proper integers.
     int offsetX = round(direction.X);
     int offsetY = round(direction.Y);
     adjacentCellX = attachCellX + offsetX;
     adjacentCellY = attachCellY + offsetY;
     var adjacentObject = grid[adjacentCellX, adjacentCellY];
     
     foreach (otherDirection in which the adjacentObject can attach)
     {
           //By the previous tests, we know these two blocks are adjacent to each other.
           //That means if one of the directions from the first block points at the second block
           //and one of the directions from the second block points at the first block,
           //attachment must be possible!
           if(Vector3.Dot(direction, otherDirection) <= -0.99)
                 return true;
     }
}
return false; //None of the adjacent objects had exposed attachment faces.

}

If you don't have a 'real' grid structure, you could use ray casts and such to get something similar. It is easier with an implicit or explicit grid structure, though.

[Socram]

Yes it does use a fixed grid system for the vehicle. Thanks for such a thorough reply as always, this idea is so much simpler than the stuff I had in mind and I feel like an idiot for not thinking of it myself.

Once again thanks for the always fast and super informative posts, by far the best support experience I've had.

Do you do any game/anything development outside of BEPU?

[Norbo]

Once again thanks for the always fast and super informative posts, by far the best support experience I've had.

Glad I can help

Do you do any game/anything development outside of BEPU?

Yup. There are a few projects in the wings that aren't public. One of them is indeed a game which helps direct the development of the physics engine.

[Socram]

Blah but if they're private then I can't track their development!!! haha

[Norbo]

Don't worry, the interesting stuff will eventually go public

And thanks for the donation!

[Socram]

Well I'll be waiting!!! Ha, and yeah no problem you certainly deserve it.

[Mindrage]

Awesome! But cant you someway link all contraints and remove them with a destructor? it would be alot easier to deal with contraints then XD

[Norbo]

While technically possible, putting it in a destructor would involve nondeterministic changes to the simulation and would require the usage of buffering. Further, a destructor only runs when the object is unreferenced and being eaten by the garbage collector. A still-referenced object, such as one in the connection fields of a constraint (which is in turn referenced by something else...), will not be collected. There's all sorts of things that would have to be done to get it done properly, resulting in much more work than alternatives.

Another option is removing any constraints involved with an entity on removal from space, but there are times where you don't want this to happen.

Given the way the engine handles constraints and other objects, it is simplest to just directly choose which elements you actually want to remove from the simulation rather than attempting to automate it in a way which isn't always helpful.