Bepu 2 mesh shape causes crash!

Discuss any questions about BEPUphysics or problems encountered.
tomweiland
Posts: 44
Joined: Wed May 08, 2019 12:17 am

Re: Bepu 2 mesh shape causes crash!

Post by tomweiland » Wed May 08, 2019 3:20 am

Norbo wrote:
Wed May 08, 2019 3:07 am
(I'm a bit surprised that works at all, actually- compounds don't technically support nonconvex child shapes like the Mesh. Unless you mean adding the triangles individually.)
This might explain it...the mesh collider that I'm able to collide with is convex (by nature, I haven't set anything to convex), although out of the 5 mesh child shapes, 2 are convex so I'm still missing one.
Or did you mean that all meshes are treated as nonconvex and therefore compounds wouldn't support any meshes at all? If so, what would be the best way of going about achieving a similar effect to them being part of a compound, or is this not possible?
Norbo wrote:
Wed May 08, 2019 3:07 am
Super long shot: are any relevant orientation quaternions not unit length?
I don't give any of the meshes rotations, so I don't think that's it.

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

Re: Bepu 2 mesh shape causes crash!

Post by Norbo » Wed May 08, 2019 3:39 am

Or did you mean that all meshes are treated as nonconvex and therefore compounds wouldn't support any meshes at all? If so, what would be the best way of going about achieving a similar effect to them being part of a compound, or is this not possible?
By nonconvex I mean any shape not implementing IConvexShape, so any Mesh regardless of actual geometry would be nonconvex in this sense.

Adding a bunch of individual Triangle shapes to a compound (a BigCompound, since the Compound type is made for tiny groups of shapes and doesn't have an acceleration structure) is allowed, though it won't have the boundary smoothing that a true Mesh has.

If this is for a mobile object, and especially if it is for a dynamic object, I strongly recommend using an approximate compound of simple implicit shapes (boxes, spheres, capsules), or if that's not possible, a compound of convex hulls. The library doesn't have any convex decomposition built into it, but a variety of content tools can do it. I think there's a VHACD implementation for blender, and there are probably a bunch of others.

Triangulated dynamic objects almost always end up behaving in a gross way due to the triangles being infinitely thin. Imagine what happens when a dynamic Mesh collides with a static Mesh- it's very easy to get into situations that require resting contact between two infinitely thin shapes. It does not produce good results :P

tomweiland
Posts: 44
Joined: Wed May 08, 2019 12:17 am

Re: Bepu 2 mesh shape causes crash!

Post by tomweiland » Wed May 08, 2019 5:52 am

Hmm I see what you're saying.

At what point does it become unfeasible/"not possible" to use a combination of simple colliders to approximate a mesh? The mesh I'm using is for the hull of a ship (about 270 vertices, needs to be dynamic), so it's pretty round and would require quite a few boxes to make the approximation believable.

Even if I use simple colliders to represent my meshes in this case, once I get around to terrain generation I'll need to use a mesh object, and the fact that my test mesh cube (not part of a compound) doesn't work either is a little worrying.

Also, by "mobile object" do you mean an object that will be part of a simulation which is run on a mobile device?

One other thing I've been wondering...what number of child shapes would benefit from using a BigCompound instead of a regular one? 10? 50? 100?

Once again, thank you for the help, it's greatly appreciated!

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

Re: Bepu 2 mesh shape causes crash!

Post by Norbo » Wed May 08, 2019 9:13 pm

At what point does it become unfeasible/"not possible" to use a combination of simple colliders to approximate a mesh? The mesh I'm using is for the hull of a ship (about 270 vertices, needs to be dynamic), so it's pretty round and would require quite a few boxes to make the approximation believable.
It's primarily an issue of authoring. For example, if the shape lacks any boxy regularity (like, say, a voxel grid), then trying to fit dozens of boxes to it will be a huge pain. In constrast, there are a lot of tools for automatically generating convex hull decompositions of meshes to varying levels of fidelity.

Performance can be a secondary issue. If the desired level of fidelity is sufficiently high, the required number of spheres/boxes/capsules may make it slower than just using fewer ConvexHulls.
Even if I use simple colliders to represent my meshes in this case, once I get around to terrain generation I'll need to use a mesh object, and the fact that my test mesh cube (not part of a compound) doesn't work either is a little worrying.
That is indeed odd. If you have a .obj file that reproduces the issue, I could stick it into the demos and see if it behaves the same. (Although I would like to figure out why the demos aren't working for you, since you probably aren't alone in that regard.)
Also, by "mobile object" do you mean an object that will be part of a simulation which is run on a mobile device?
Just any object capable of movement, so a kinematic or dynamic body. Dynamic bodies are more concerning since kinematics can't respond to collisions anyway (infinite mass and all that). The core issue is avoiding situations where two infinitely thin triangles need to generate reliable contacts over time, since they just won't.

(Notably, meshes with solidity solve this issue and v1 supported them, but the universal recommendation was 'never use them' for performance reasons. I just dropped the feature. I might revisit this down the line with a more clever approach, but until then, dynamic meshes are evil.)
One other thing I've been wondering...what number of child shapes would benefit from using a BigCompound instead of a regular one? 10? 50? 100?
There's not a fixed threshold, but <4 will very likely prefer a Compound, while >20 will very likely prefer a BigCompound. The only way to know for sure is to measure for a particular use case. BigCompound is a relatively 'safe' choice in that, even when it is slower, the overhead isn't that big of a deal. In contrast, a Compound with 3000 elements in it can be very slow due to not having any acceleration structure.

tomweiland
Posts: 44
Joined: Wed May 08, 2019 12:17 am

Re: Bepu 2 mesh shape causes crash!

Post by tomweiland » Wed May 08, 2019 11:18 pm

Norbo wrote:
Wed May 08, 2019 9:13 pm
That is indeed odd. If you have a .obj file that reproduces the issue, I could stick it into the demos and see if it behaves the same.
Could the file format affect behaviour in some way? I don't have a .obj file - since my client runs in Unity, I have the blender file directly in there, and I just use Unity's mesh.vertices and mesh.indices to grab the vertices and indices and paste them in a .txt file, which I read out server side.

It might be worth noting that this method of extracting the mesh data (while it likely isn't the most efficient/best) worked flawlessly with BepuPhysics v1.
Norbo wrote:
Wed May 08, 2019 9:13 pm
(Although I would like to figure out why the demos aren't working for you, since you probably aren't alone in that regard.)
So to confirm, I should be able to just open the Demos solution and run it and it should give me something other than an empty console window? That's what I got yesterday.

Strangely enough, when I tried it again just now, the console window popped up (still empty), and then a window titled "pretty cool multicolored window" popped up. The window didn't display anything (just plain white background), and then I got the following exception at line 57 of RenderSurface.cs:

Code: Select all

HRESULT: [0x80004005], Module: [General], ApiCode: [E_FAIL/Unspecified error], Message: Unspecified error
The line in question:

Code: Select all

Device.CreateWithSwapChain(DriverType.Hardware, enableDeviceDebugLayer ? DeviceCreationFlags.Debug : DeviceCreationFlags.None, swapChainDescription, Device device, out swapChain);

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

Re: Bepu 2 mesh shape causes crash!

Post by Norbo » Thu May 09, 2019 12:27 am

Could the file format affect behaviour in some way? I don't have a .obj file - since my client runs in Unity, I have the blender file directly in there, and I just use Unity's mesh.vertices and mesh.indices to grab the vertices and indices and paste them in a .txt file, which I read out server side.
It shouldn't affect anything (assuming there are no bugs), but the demos content pipeline only supports .objs. I could use a blender file too, just anything I can use to reproduce the issue locally.

Another option would be to programmatically create a mesh (like a simple heightmap or something). If you can reproduce the issue with that, then I can just work with a pure code snippet.
So to confirm, I should be able to just open the Demos solution and run it and it should give me something other than an empty console window?
Yup, it should look something like this if:
1) your GPU supports DX11,
2) OS is Windows 7+ (though I've had at least one report that seemed to indicate problems on windows 7, though I'm not yet sure why), and
3) a Windows SDK installed for the DX11 compiler dependencies.

I'd expect a lack of Windows SDK to show up as failed build tasks (the content pipeline wouldn't be able to compile the shaders), so it's probably not that.

If your environment meets all those requirements and it's still failing, there's some other issue. Unfortunately these issues tend to be a bit annoying to debug, and even moreso remotely. If you're up to it, you can enable the DX debug layer and see if it's complaining about anything- instructions can be found on the related github issue: https://github.com/bepu/bepuphysics2/issues/68

tomweiland
Posts: 44
Joined: Wed May 08, 2019 12:17 am

Re: Bepu 2 mesh shape causes crash!

Post by tomweiland » Wed May 22, 2019 12:46 am

Norbo wrote:
Thu May 09, 2019 12:27 am
I could use a blender file too, just anything I can use to reproduce the issue locally.
I was actually just extracting the vertices and indices from a Unity cube and pasting them into a .txt file which I read in the program with Bepu integrated. Maybe it's an issue with my code, but you said that what I posted earlier looks like it should work.
Norbo wrote:
Thu May 09, 2019 12:27 am
Another option would be to programmatically create a mesh (like a simple heightmap or something)
I'll look into this once I get around to terrain generation (which may be a few weeks) and I'll post back here (assuming the issue isn't resolved by then).
Norbo wrote:
Thu May 09, 2019 12:27 am
1) your GPU supports DX11,
Not entirely sure about this one - Unity says "PC, Mac & Linux Standalone <DX11 on DX10 GPU>" in the top right corner...
Norbo wrote:
Thu May 09, 2019 12:27 am
2) OS is Windows 7+ (though I've had at least one report that seemed to indicate problems on windows 7, though I'm not yet sure why), and
I'm on Windows 7.
Norbo wrote:
Thu May 09, 2019 12:27 am
3) a Windows SDK installed for the DX11 compiler dependencies.
Am I mistaken in assuming that this would only apply if I'm running Windows on a Mac or something?

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

Re: Bepu 2 mesh shape causes crash!

Post by Norbo » Wed May 22, 2019 1:09 am

Not entirely sure about this one - Unity says "PC, Mac & Linux Standalone <DX11 on DX10 GPU>" in the top right corner...
dxdiag's System tab has a "DirectX Version" field you can check. The per display device tabs also include information such as what feature levels are supported.
Am I mistaken in assuming that this would only apply if I'm running Windows on a Mac or something?
I don't think the Windows SDK ships by default with Windows, so it would apply for anyone who hasn't already installed it for some other purpose. But I'd expect the lack of the SDK to cause compile-time errors, since the shader compiler runs as a build task. If the build passes, it's probably something else.

tomweiland
Posts: 44
Joined: Wed May 08, 2019 12:17 am

Re: Bepu 2 mesh shape causes crash!

Post by tomweiland » Wed May 22, 2019 1:38 am

Norbo wrote:
Wed May 22, 2019 1:09 am
dxdiag's System tab has a "DirectX Version" field you can check. The per display device tabs also include information such as what feature levels are supported.
I have DX 11.

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

Re: Bepu 2 mesh shape causes crash!

Post by Norbo » Wed May 22, 2019 8:43 pm

I have DX 11.
Unfortunately I'm out of ideas on that front then- figuring it out would likely require running the DX debug layer as described here to see what it has to say, if anything.

With regards to the original issue, I forgot to mention that the BufferPool.Take change to return a tightly bounded buffer was implemented a while ago.

Out of curiosity, if you set up a minimalist static mesh like this, does it work as expected? This works fine in the demos, so if you still see something wonky, it may help narrow down potential sources.

Code: Select all

            BufferPool.Take<Triangle>(1, out var triangles); //assumes that the new version with BufferPool.Take change is used
            triangles[0] = new Triangle(new Vector3(0, 0, 0), new Vector3(10, 0, 0), new Vector3(0, 0, 10));
            var mesh = new Mesh(triangles, Vector3.One, BufferPool);
            Simulation.Statics.Add(new StaticDescription(new Vector3(0, 10, 0), new CollidableDescription(Simulation.Shapes.Add(mesh), 0.1f)));

tomweiland
Posts: 44
Joined: Wed May 08, 2019 12:17 am

Re: Bepu 2 mesh shape causes crash!

Post by tomweiland » Thu Jun 27, 2019 3:49 pm

A little update: I started working on terrain generation a few days ago, so I had to come back to using meshes. This time, I decided to construct the mesh programmatically, directly on the server (instead of extracting vertices/indices from Unity) and it works great. That makes me think that maybe the way Unity stores indices in its mesh data doesn't work too well when trying to feed it to Bepu :?

I do have one question about the memory usage though. When I add a mesh with 10201 vertices (20000 tris), my memory usage jumps by ~8.5MB, which seems unusually high to me. Is that kind of jump to be expected for a mesh of this size, or is something amiss here?

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

Re: Bepu 2 mesh shape causes crash!

Post by Norbo » Thu Jun 27, 2019 11:12 pm

When I add a mesh with 10201 vertices (20000 tris), my memory usage jumps by ~8.5MB, which seems unusually high to me. Is that kind of jump to be expected for a mesh of this size, or is something amiss here?
Here's a breakdown of memory for creating a 128x128 heightmap-ish Mesh:
32258 triangles, allocated buffer size of 58254: 2097152 bytes
Temporary allocation of bounding boxes for use in Tree.SweepBuild: 1049176 bytes
Other miscellaneous temporary allocations in Tree.SweepBuild: 1970432 bytes
Tree nodes, metanodes, and leaf structures: 2755712 bytes

The total allocations from creating the mesh to adding it to the simulation are 8137088 bytes.

A few notes:
1) These values were measured by direct examination of buffers and querying the GC (GC.GetAllocatedBytesForCurrentThread) directly. Process-level memory usage statistics won't provide the same level of precision because they're measuring something else.
2) The temporary allocations for bounds and sweep builder scratch data are returned to the pool when construction is complete. From the perspective of the GC, so long as the BufferPool exists, that memory is still 'in use' but in reality it will be reused by later requests to the BufferPool.
3) The BufferPool's custom allocator is not primarily concerned with total memory usage- it leaves dead space sometimes to avoid the difficulties of fragmentation and to keep allocation/deallocation costs very low. The tradeoff is that something like the Triangles allocation in the above example ended up taking almost twice as much memory as it needed.
4) A heightmap specialized mesh type could use an order of magnitude less memory by making use of the regular structure, but I didn't add one in the first release since physics-related memory capacity is effectively never a bottleneck on my target platforms. One may still appear later.
5) If two meshes have the same underlying triangle data and acceleration structure and differ only in position/rotation/scale, you can reuse the same Triangles and Tree in another Mesh instance without needing to allocate more space.

Post Reply

Who is online

Users browsing this forum: Yandex [Bot] and 7 guests