Using CollisionShape’s SetTriangleMesh on Custom Geometry object throws exception

So I’ve been trying to give physics to objects made with Custom Geometry (Same as DynamicGeometry sample) but when I do

node->CreateComponent<ur::RigidBody>()->SetMass(1.0f);
ur::CollisionShape *shape= node->CreateComponent<ur::CollisionShape>();

shape->SetTriangleMesh(object->GetModel(), 0);

It throws an exception, around the shape->SetTriangleMesh part.
I’ve also tried using the actual model variable but that throws an exception, too.

Here’s how the model is made

ur::SharedPtr<ur::Model> model(new ur::Model(context_));
ur::SharedPtr<ur::VertexBuffer> vb(new ur::VertexBuffer(context_));
ur::SharedPtr<ur::IndexBuffer> ib(new ur::IndexBuffer(context_));
ur::SharedPtr<ur::Geometry> geom(new ur::Geometry(context_));

ur::PODVector<ur::VertexElement> elements;
elements.Push(ur::VertexElement(ur::TYPE_VECTOR3, ur::SEM_POSITION));
elements.Push(ur::VertexElement(ur::TYPE_VECTOR3, ur::SEM_NORMAL));
elements.Push(ur::VertexElement(ur::TYPE_VECTOR3, ur::SEM_COLOR));
elements.Push(ur::VertexElement(ur::TYPE_VECTOR2, ur::SEM_TEXCOORD));
elements.Push(ur::VertexElement(ur::TYPE_VECTOR4, ur::SEM_TANGENT));

vb->SetShadowed(true);
vb->SetSize(numVertices, elements);
vb->SetData(vertexData);

ib->SetSize(36, false);
ib->SetData(indexData);

geom->SetVertexBuffer(0, vb);
geom->SetIndexBuffer(ib);
geom->SetDrawRange(TRIANGLE_LIST, 0, numVertices);

model->SetNumGeometries(1);
model->SetGeometry(0, 0, geom);
model->SetBoundingBox({min, min + max});

Any clue?

Could you please provide backtraces?
Also isn’t there SetCustomTriangleMesh()?

SetCustomTriangleMesh() is only for the CustomGeometry class, and I don’t find it necessary having to manually convert every custom object into CustomGeometry JUST for an easier solution.

Here’s the stack trace.

It would be great if you publish model and example to help others investigate the problem

Alright.
Here’s the full code of how to make a custom geometry
https://hastebin.com/ibekukubow.go

Reproduced.
Will investigate it.

IndexBuffer must be shadowed too.

Probably Urho need better error reporting somewhere around TriangleMeshData

Thank you, that worked. I got rid of it because it would throw a ton of exceptions randomly and occasionally. Thought I didn’t need it.

Guess I did

Is there some reason for

ib->SetShadowed(true);
ib->SetSize(36, false);

Randomly throwing exceptions?
It seems to have no pattern and happens sometimes.

It’s hard to say anything without callstack.

Found it. Happens pretty rarely so took me a few tries.
Exception: http://prntscr.com/fjc1xm
Call Stack: http://prntscr.com/fjc27u

Do you use OpenGL build of Urho?

Why do you say numVertices = 36 if you have only 8 vertices?

Yes I used the OpenGL Build.

I assumed the numVertices was the number of indices, not vertices. Should it be vertices?

I assume that numVertices is the number of vertices

Looks like that solved it, you’re a lifesaver!
All that’s bugging me is the Cubes glitching together.

No chance to help without related code

Alright, alright. Should’ve known
Here’s the same function but improved used to make Cubes: https://hastebin.com/sutewulome.php
Here’s where I define the Bricks: https://hastebin.com/xatuvodevu.php (“data” is a struct containing Scene, Context and so on)

scene_->CreateComponent<ur::PhysicsWorld>();

is declared, too.

Triangle meshes are not allowed to be movable. Use convex hull or other primitives.

Didn’t know convex hulls were valid, thanks! It works now!

Just a tad bit glitchy, which is fine for now I guess.

This is crazy. I re-watched this video ten times trying to understang logic of this physic.
Try to draw PhysicsWorld debug geometry to ensure that physical colliders are the same as drawables.
My test app works fine: Editor with two cubes and plane.

Here:

From what it looks like a few lines appear to disappear and reappear randomly.

This physics make me headache.

Just a random thought.
AFAIK, Bullet interprets (0, 0, 0) as the center of mass of the body.
Your boxes don’t contain (0, 0, 0) and this may make Bullet insane. But I am not sure. Try to use boxes that contain zero point.

I’m going to try the Model’s SetGeometryCenter() function and see if that helps.

EDIT: I don’t believe that works as neither

model->SetGeometryCenter(0, {min + (max / 2)});

or

model->SetGeometryCenter(0, {max / 2});

help at all.
Having it freeze like this: http://prntscr.com/fjf244 is a bit interesting through.

I’ve checked code right now. It looks like Set/GetGeometryCenter logic isn’t used by Urho at all. It literally does nothing.

Well that’s strange
Don’t know of any other way to set the origin/center of the model.

Try to fix cube’s vertices first to make 'em contain (0,0,0). If it works, think about nicer solution.

I attempted to move the plane 20 down the y axis and make the red rectangle have 0,0,0 in it
The blue cube was on it, fell off, and did a bowling pin strike on it and knocked the red rectangle down.
Extremely bizarre.

You still have bad physic shapes.
Let me show.
Red brick has its center of mass at the edge of box, 5 units from the top.
Blue brick still has out-of-shape center of mass.
Both variants are physically meaningless. There is no valid way to simulate such bodies. Center of mass must lay inside the body.

Okay! I think I got what you mean.
I’ll try to find a function to set the center of mass or origin point.

AFAIK, there is no such function. Urho probably inherited this Not Very User Friendly intefrace from the Bullet. Generic way is to prepare physic body with center of mass at zero and then use node transforms to move it.

It shan’t be very hard to add ‘Center of Mass’ parameter to RigidBody, but it shall be implemented very carefully since there is a lot of complex logic.

If I’m understanding you then I should set the transformation of the node to make the position the center?
I’m doing node->SetTransform(-max / 2, {0.0f,0.0f,0.0f}); Which does make the origin point the center, yet that still doesn’t work.

First of all, you should ensure that zero coordinate is inside of the shape described by vertices.
Tune parameters of your bricks to achieve this.

Oh my god, thank you! That worked!

I think I’m going to make some sort of system of them being spawned at 0,0,0 then moved.
Thank you for your tremendous help!

I am glad to hear it.

Try to keep center of mass physically valid. Parameters of Brick constructor are the corner and the size of the cube. Your corners contain zero Z coordinate. This means that center of mass is on the top face of the cube. This is still error-prone, because ‘valid’ physical objects can’t have CoM at the surface. This may lead to unnnatural movements. Just beware.

The funny thing is that you often need to have center of mass out of your body, especially in vehicle simulation cases.
Of physics engines only Havok supports this straight-forward way, as it allows rotational momentum offsets.
BTW, it is not possible to have proper collision AND proper vehicle physics in Urho, i.e. cars will always stand on wheels and never lay on roof. Or you have to use box as collision (which will properly rotate and flip, but will not collide properly). So you can’t have different bodies for physics momentum calculations and collisions, which is not nice…
I wonder why so little physics engines do this… It is probably possible to do this in Bullet, but it looks like nobody did this.

May you explain the physical meaning of such CoM and how it should behave?
It’s hard for me to understand.

Yeah! My system works perfectly.

How it works is that it creates it with 0,0,0 in the center and then moves it to the desired position and sets it’s mass.

You might want to read my whole post.
CoM in Bullet is used for 2 purposes - center of actual mass and a point around which a body rotates.

Imagine the following - you want a van, which is hard to handle, i.e. if you turn in too short radiuses, it will lay on side.
For that to actually work you need to offset the actual center of mass to up of the body (Volition guys do offset center of mass even above the body, which I mention, but I don’t insist on it), but it should still turn around middle or bottom.
Otherwise it simulates orbiting planet (which is still good example of having CoM out of body, but that is not important
for my point). This is where bullet is lacking in simulation of vehicles and other things. The offset of CoM is minimum
required thing. You need to specify somehow that top of body is heavier than bottom, even though collision mesh on the above is smaller. This makes it extremely hard to do GTAIII-style vehicle physics I aim for,
The only partial workaround I found was to change collision shape to convex hull if collision happens with anything but ground. Otherwise use box. But this does have a lot of artefacts. For most effects it is easier to just animate thing
in Blender than use physics. Volition guys use Havok, which uses separate bodies for collision and physics calculations. I really want something like this implemented for Urho, but I really don’t know enough to even imagine this.

If you make your vehicle thinner, lighter, higher. Make the wheel spin faster and have the steering wheel to turn faster. Have slightly higher coefficient of friction. If your car run at a fast speed, with a sudden turn, it will roll over like no tomorrow.

I think centre of mass calculation usually assume uniform distributed weight, which is the location of the centroid of the geometry.

Well, there are poor man tricks for this, like making cars flatter and boxier (like in original GTAIII),
but that is really not something which I want to do. I;d prefer something more life-like without weird tricks.

Also if you use realistic collision shapes, physics in Bullet makes it not possible for car to not get to wheels.
For some people it is nice and cool, but if you want to make sure car will behave more realistic (i.e. stays on roof or side) it is not possible to do unless you set collision shape as box. So Bullet is wicked and strange. I remember working with some OSS engine which allowed offsetting of center of mass, but I don;t remember the details. The only one I know working regarding this is Havok. Anyway, with Urho we have only Bullet, and it doesn’t allow to do adequate vehicle physics.

From the Bullet Forums:

I wonder why people here think I can’t use Google

As I mentioned before, it is necessary to have CoM != CoG != pivot.

The best is to have different collision shapes for collision and momentum calculations (forces calculations).
The minimum - have CoM offset.
Otherwise you make flat/boxy cars, use box collisions and model your graphics knowing you need CoM at center.

I wonder why people use Google at all.

Example: You have van-type vehicle with high CoM. because CoM == pivot, the behavior will be unrealistic.
One can use tricks like shifting geometry + collision at run time in some cases, but not many, in general one have to either animate physics behavior or just exclude vehicle complex behaviors from gameplay.

For Unity, which doesn’t have this problem, they resolve some issues like this:

https://forum.unity3d.com/threads/how-to-make-a-physically-real-stable-car-with-wheelcolliders.50643/

Also it looks like Bullet uses CoG, not CoM for momentum, so moving CoM from CoG using offsets of collision
bodies make physics behave weird. i.e. if I move CoM farther from CoG the body rotates longer and with more energy than if CoG os closer to CoM, which makes me think that rotational momentum is considered so that CoG is forces center, thus body sometimes have explosive rotation. Try long and thin CollisionShapes with CoM offset to one end, and apply torque to them. So if one wants to do cars for Urho3D which behave properly, he will have to be able to override forces so that to have control over CoM and rotational momentum regardless of geometry of collision shapes,
or even make possible to use different bodies for forces and for collisions. That would be very interesting challenge,
too bad I don’t have time for it ATM, probably somebody more experienced in physics engines can do it.

BTW, as I see you use RaycastVehicls stuff in your little game. How the stuff is going? I want to see YOUR cars rolling!
(and siding and other cool stuff like getting in/out of car)…

I’ve been working on other projects. I was pretty content with the driving earlier, but messed up some values - now the cars are all wobbly - and decided to look into it later. Some vehicle editor with built-in test-drive mode would be ideal.

Actually I don’t think I want functional cars in OGTatt to be able to roll over, for gameplay reasons. Moving their centre of mass down is exactly what I intend to do, maybe with an angle limit before 90 degrees.

Well, I did the editor for myself but it is heavily attached to my car structure, I don’t think it might be used for anything else…
I think you could use just separate scene where you can tweak all values in text file and drive, that is easier than making whole editor and have the same level of usability.