The correct way to change the custom mesh size.

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
ProBAR
Posts: 10
Joined: Tue Aug 05, 2014 9:46 pm

The correct way to change the custom mesh size.

Post by ProBAR » Mon Apr 24, 2017 10:41 am

Hello!

I've noticed BEPU does not support real-time scaling. Is there any way to do this without recalculating vertices and indices of original mesh? If exists then how to do it as fast as possible for case when topology is not changed? And separate way when changed?

I need this for my little puzzle game, where player can resize the key that unlocks the doors with different sizes of locks (unlocking based on physics).
P.S.:
Speech: English is not my native language, so I apologize in advance for my mistakes.
Language: Mainly Visual Basic.Net, of course not excluded C#.
Using BEPU: I get it from the NuGet Packages (very handy, thanks!).
Render: SharpDX.

Norbo
Site Admin
Posts: 4542
Joined: Tue Jul 04, 2006 4:45 am

Re: The correct way to change the custom mesh size.

Post by Norbo » Mon Apr 24, 2017 5:41 pm

StaticMeshes and InstancedMeshes both have a WorldTransform property. It can handle scaling transforms, and setting it calls the necessary refit operation internally. Refit operations are much, much cheaper than the full Reconstruct operation, but only work when topology doesn't change. If you need to change topology, you'd have to do something similar to what the WorldTransform property does internally, but with a Reconstruct.

MobileMeshes are entities, which only support rigid transforms, so it requires a bit more work. There's no built in way to do this super efficiently, but you could just reconstruct a MobileMeshShape using the raw constructor that takes every property. This will still suffer some GC overhead, though. If you want to avoid GC overhead, you'll need to dive a bit deeper and modify the source to allow post-construction modification. If you do everything that constructor does in a GC-less manner, it should work. (I didn't do it mostly because don'twannait'sgross. v2 will make this sort of thing easier.)

In all cases, be aware that many forms of collision detection that cache contact data between frames are not aware of resizing since it's not a physical operation in the context of the engine. It's possible that some contacts will stick around that shouldn't- if you notice some weird contact behavior, it may be a good idea to clear all the contacts associated with the resized object. Contact caching is important for stability under normal circumstances, so it should be avoided unless necessary.

To clear contacts:

Code: Select all

            foreach(var pair in (some collidable, e.g. StaticMesh or entity.CollisionInformation).Pairs)
            {
                pair.ClearContacts();
            }

ProBAR
Posts: 10
Joined: Tue Aug 05, 2014 9:46 pm

Re: The correct way to change the custom mesh size.

Post by ProBAR » Mon Apr 24, 2017 7:28 pm

Thank you for your detailed response!

I'm using MobileMeshes for keys and unlockers exactly for transformations and animation. Apparently I have to use a little trick. At a time when the player changes the size and position of the key, the object will be presented as static mesh. When he's finished, I'm building a mobile mesh from the resulting topology from the static mesh.

In your opinion is this method acceptable?
P.S.:
Speech: English is not my native language, so I apologize in advance for my mistakes.
Language: Mainly Visual Basic.Net, of course not excluded C#.
Using BEPU: I get it from the NuGet Packages (very handy, thanks!).
Render: SharpDX.

Norbo
Site Admin
Posts: 4542
Joined: Tue Jul 04, 2006 4:45 am

Re: The correct way to change the custom mesh size.

Post by Norbo » Mon Apr 24, 2017 7:45 pm

If it works, it works :)

From a nitpicky standpoint, that will end up generating a good bit of garbage. Whether that's acceptable is up to you. Without knowing more about the problem it's hard to provide any further advice, but I generally recommend avoiding dynamic meshes whenever possible. They're easily an order of magnitude more expensive than simpler primitives before taking into account all of the reconstruction costs. In other words- if it is at all possible to represent the desired shapes with primitives or compounds of primitives rather than a mesh, it's probably a good idea to do so.

ProBAR
Posts: 10
Joined: Tue Aug 05, 2014 9:46 pm

Re: The correct way to change the custom mesh size.

Post by ProBAR » Mon Apr 24, 2017 8:01 pm

OK, I'll test all these options. I'll see how the garbage collector will handle it. Also how much is a large delay between frames will be.

Interestingly, in version 2.0 are there any easier solutions for this issue? Asking for the knowledge.
P.S.:
Speech: English is not my native language, so I apologize in advance for my mistakes.
Language: Mainly Visual Basic.Net, of course not excluded C#.
Using BEPU: I get it from the NuGet Packages (very handy, thanks!).
Render: SharpDX.

Norbo
Site Admin
Posts: 4542
Joined: Tue Jul 04, 2006 4:45 am

Re: The correct way to change the custom mesh size.

Post by Norbo » Mon Apr 24, 2017 8:42 pm

As a general rule, v2 gets out of the way and trusts the user more.

For example, the engine assumes all shapes are immutable value types (even if they aren't internally immutable pure value types). If you do something that violates this assumption, it's your job to deal with it. Oddly enough, this actually simplifies things in this case: since the engine isn't tracking anything, you can freely modify whatever you want in the shape. The API won't force you to allocate new GC-tracked stuff.

Once you've changed the shape, you can then update the other properties of the related entities if you want/need to- like the inertia tensors. Or not. Small changes in inertia tensors are pretty hard to see, and faking the inertia by using a box's inertia instead would likely work 99.9% of the time. But you'll probably still want to clear out the contacts unless I do something weird like move entirely to one-shot manifolds, which isn't super likely.

There will also probably only be one mesh type that covers what the current StaticMesh, InstancedMesh, and MobileMesh do. They're all practically the same anyway. So there would never be a situation where you need to use a different underlying mesh shape to get different functionality.

Also, the underlying tree used for the meshes (and everything else that needs a tree) is going to be much faster, so topology changes won't be such a big deal- from both runtime and GC perspectives.

ProBAR
Posts: 10
Joined: Tue Aug 05, 2014 9:46 pm

Re: The correct way to change the custom mesh size.

Post by ProBAR » Mon Apr 24, 2017 9:23 pm

So with version 2.0 we need to use it more carefully. I hope the demos will show us how to do it in the right way :D

Norbo wrote:
Mon Apr 24, 2017 8:42 pm
There will also probably only be one mesh type that covers what the current StaticMesh, InstancedMesh, and MobileMesh do. They're all practically the same anyway. So there would never be a situation where you need to use a different underlying mesh shape to get different functionality.
It sounds great, to be honest.

"Blazing Fast Trees" - I have already read this article as soon as it was announced. Super awesome work. What a progression!
I am looking forward to start using it when version 2.0 will be released.

Thank you so much Norbo!
P.S.:
Speech: English is not my native language, so I apologize in advance for my mistakes.
Language: Mainly Visual Basic.Net, of course not excluded C#.
Using BEPU: I get it from the NuGet Packages (very handy, thanks!).
Render: SharpDX.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests