Problem with MeshPart Collision (Came back again)

[Fnara10]

Hello,

I have (again) a problem with incorrect collision behavior for mesh type parts.

The last time this problem occurred was on August 15th. And described in the user’s post twonty.
Physics engine simulating excessive bumpiness over MeshPart surfaces

The engine stopped working correctly on physics at mesh nodes.

Last time the problem was resolved during the discussion of that post between Twonty and the developers. (post)

To be completely precise, the problem itself was identified to me a couple of weeks earlier, I just couldn’t write anything on the forum.

But thanks to Twonty and the Roblox team, the problem was then fixed

However, today, September 22, after updating Rolbox, the problem returned again.

I have screenshots of the problem:

3. and even a test scene.

4. I just can’t place my request in the correct section of the forum.

I understand that I needed to supplement the previous topic and generally write in the “bug report” section and in the “Engine bug”. However, as a new user, due to forum rules, I cannot do this. I couldn’t even write anything at all for a whole month, and couldn’t participate in the discussion.

Finally, there was an opportunity to write somewhere.

And, of course, if someone can escalate the problem to the correct section of the forum, I will be immensely grateful.

[z1xzaxz1x]

Hello we have verified that the collision behavior didn’t change in this test case during the last few weeks. Can you confirm that this was working as expected before the 22nd. This doesn’t seem related to the the issue you linked either.

Upon debugging this, it looks like the convex decomposition of the rail section near where the bug is reported is not exact and is pushing the wheels upwards as seen in these images. This is a result of our approximation during convex decomposition. To fix cases like this, It is better to create templates of rails with different curves, test them individually for proper physics given our approximations. and then assemble them into a long rail.

[Fnara10]

Hello!

Thanks for the answer!

Unfortunately, I cannot give the exact time when this problem occurred, but most likely it appeared during the period of one or several days before the morning of September 22.

You are right, the example I attached to the first post is not entirely correct. I didn’t notice that the mesh in question uses the “PreciseConvexDecomposition” collision model.
Obviously, at the moment, on such a grid, such a collision model cannot be used at all in my simulation, since it obviously incorrectly reflects the physics of the process.

Probably the test scene was saved when I tried to reproduce the bug last time.

However, in my main game, all meshes (rails) use the “Default” collision mode. Here’s an example of what a typical object looks like (quite complex, but containing elements of varying lengths).

However, problems arise both in complex sections and on the simplest curve from the previous sample (in the “default” mode, of course)

Apparently I won’t be able to create a simple scene that could reproduce this problem, but I’ll try to take some screenshots and the moments that confuse me.

A number of individual elements have rather strange visualization of collision geometry. (Perhaps the characteristics of the Studio, but perhaps not).

This is how it looks in “Vertex”:

What also confuses me is that in the “Default” collision model there is a structure in the form of a pyramid with a visible slope.

In general, the process results in wheelsets being thrown unpredictably out of their expected position.

This really upsets me. Because at the end of spring/beginning of summer I did a lot of research on the capabilities of the engine and became convinced that models from meshes are simply an order of magnitude better for the smoothness and stability of physics than a set of the same elements from “Parts”.

And yes, the last time a similar situation was observed in the period from the first week of August to approximately
15th. This is probably a coincidence, but the problem was then mystically resolved literally immediately after the support service responded to the above post from Twonky.

[Fnara10]

Greetings, dear colleagues.

Today (October 4th) MeshPart collisions suddenly started working correctly again. And all movement through MeshPart objects or simple Part objects happens as expected (more or less).

There are no visible changes. Among other things, the oddities in decomposing collisions of MeshPart objects in the default mode (which I use) also remained unchanged…

But, otherwise, everything worked (again, like in August).

However, I will attach screenshots of the decomposition… they are, of course, a little strange.

Source object:

Result: