Q&A [Yet another thread by tree786]

[frutas-fruit]

[xissburg]

Yes I saw that the thread was deleted. I haven't seen that happen before.

[xissburg]

You could go to the EnTT discord and ask questions there. I am always there.

I have added friction to the point and hinge constraints btw, and also limits to the hinge. More info in the docs.

[Green-Sky]

Hey, I am an interested reader of edyn notifications, and I think you guys bugged out github:

GH tells me I have notifications, while I don't have any. I think this is because tree commented and then got shadow baned....

[xissburg]

@Green-Sky yes, that's what's been happening. All posts are deleted when the account gets banned.

[Green-Sky]

This is actually frustrating for me, since the notification bell is permanently lit.
And I can't access the extra notifications:

[xissburg]

@Green-Sky this looks like a bug on Github. Perhaps worth submitting a bug report.

[frutas-fruit]

[xissburg]

There is not a direct way of doing that. Currently, you'd either have to destroy and recreate the entity or remove all edyn components from it and create a rigid body again reusing the same entity.

Changing the rigid body type would require some additional things to be done internally, such are rearranging certain components, moving the entity from the static broad-phase AABB tree into the dynamic, marking them as procedural, changing the nodes in the entity graph to be connecting nodes. It is possible but not trivial.

[frutas-fruit]

[xissburg]

Could you try linking -lpthread?

[Green-Sky]

since you are using cmake, try:

find_package(Threads REQUIRED)
target_link_libraries(binary Threads::Threads)

https://cmake.org/cmake/help/latest/module/FindThreads.html

[Green-Sky]

to me this looks like you are using diffenrent compilers / libc s for your project and for edyn. there probably is a linking flag missing that got used for edyn. how did you "install" edyn?

[Green-Sky]

just saw that edyn links against "dl". do you too?

[frutas-fruit]

[xissburg]

The generic_constraint is still too basic and incomplete, as it does not offer any limit adjustment. For ragdolls a conical constraint would be needed, i.e. which restricts the angle between two axes fixed along two bodies. Plus, it needs to restrict rotation along that axis.

[xissburg]

None at the moment :/
You could try writing one. I guess you just need to keep the dot product of the two axes above a certain value.

[xissburg]

Bullet has a btConeTwistConstraint which is a bit complicated and has a bunch of parameters. I can add this to my todo list but it'll take a while to get this to work correctly.

[frutas-fruit]

[xissburg]

If you want any tangential direction, you can use edyn::plane_space. If you want a distinct direction then you have to be more specific. Is that a tangent vector that lies in the plane which contains n and the ray direction?

[frutas-fruit]

[xissburg]

Calling edyn::rigidbody_apply_impulse or edyn::rigidbody_apply_torque_impulse should wake up the rigid bodies. Are you calling these functions?

[xissburg]

It was a bug. Must be fixed on master now. Thanks for finding it :)

[xissburg]

Is there a way to check if the body is in sleep mode? like an is_sleeping bool value? I know I can check to see if the velocity magintude is 0, but if there is a sleeping bool value i'd use that instead

You can check for the presence of a edyn::sleeping_tag, i.e. registry.any_of<edyn::sleeping_tag>(entity).

[frutas-fruit]

[xissburg]

Difficult to tell what's wrong. Could you try dropping the car without wheels onto the terrain in different orientations?

[xissburg]

Collision meshes do not have to be very detailed in general. They have to loosely represent the shape of the object, simply because that is "good enough". E.g. you probably do not need holes for the fenders, it could just be flat the whole length of the vehicle.

In Blender, while in Edit Mode, you can select all faces and got to Mesh > Convex Hull and it will make the mesh convex.

[xissburg]

That assertion probably happens due to duplicate vertices or sliver triangles, which prevents some normal vectors from being calculated, thus leading to normals.size() == num_faces() being false.

If you could post the obj file here I will test it and see if I can find any bugs.

[xissburg]

Another thing I remembered now is that you have to check your normals in Blender, which you can enable here:

Looking at your obj mesh I see that the parts in the rear of the car have the normals pointing inwards. You'd have to flip them, using ctrl + shift + N.

Your mesh also has internal faces. The shapes have a face in the middle section:

On another note, I've created the necessary constraints and a rag doll building utility https://github.com/xissburg/edyn/wiki/User-Manual#rag-dolls

[frutas-fruit]

[xissburg]

Perhaps the jumping behavior happens due to the island being awaken? I am not sure I've seen this happen before. Maybe it's due to the way you're modeling the car springs? I don't think raycasts would cause this, as they're currently done in the main thread (will be multithreaded in the future) and they don't awake islands or anything.

In debug mode things can get quite slow, in part due to asserts, including asserts within EnTT. You can try setting the EDYN_DISABLE_ASSERT option in CMake to true, which will also disable EnTT asserts, e.g. in edyn/build, run:

cmake -DEDYN_DISABLE_ASSERT=True ..

[xissburg]

I guess you need to run the cmake command because the values are cached.

[xissburg]

Can't you add more -D options? Separate by comma... I don't know.

[frutas-fruit]

[xissburg]

Where does the crash happen? Are you running it with a debugger?

[frutas-fruit]

[xissburg]

It should run correctly without vsync, i.e. the frequency with which edyn::update is called does not matter since the simulation happens in background threads and the calls to update just does synchronization with the main registry and island management. The simulation always runs with fixed time steps in the background threads.

I suspect your force calculation might not be right, because you must be applying impulses. Note that impulse equals force x time. That means you should be calculating the impulse from the force you want to apply times the delta time, which you will have to calculate yourself (you could for example just call edyn::performance_time() and calculate the difference with the value returned by it in the previous update).

When running logic in an external system vsync is also irrelevant since the external system updates will be done in tandem with the simulation step in the background threads.

[frutas-fruit]

[xissburg]

The edyn/build_settings.h file is generated after build and stored in edyn/build/include so you should add that to your include path.

[frutas-fruit]

[xissburg]

There's currently no way of doing this in Edyn. What you can do for now is to create a dynamic rigid body with a capsule shape and to prevent rotations set inertia to zero, such as:

registry.replace<edyn::inertia>(entity, edyn::matrix3x3_zero);
registry.replace<edyn::inertia_inv>(entity, edyn::matrix3x3_zero);
registry.replace<edyn::inertia_world_inv>(entity, edyn::matrix3x3_zero);

Then you apply forces to it. Another solution which is still not supported would be to assign a fake tangential velocity at the contact point on the bottom to make it work like a spinning wheel, but that will require creating an extra component later which stores this fake velocity and the contact constraint preparation code will have to add it as a constraint bias.

To make a kinematic character controller the same technique employed in the position solver of contact constraints will be used. It's essentially an iterative solver akin to sequential impulses that applies small corrections to each contact point successively over multiple iterations. Though that's yet to be planned and implemented as a separate kinematic constraint solver.

[frutas-fruit]

[xissburg]

Ok interesting. Will that be exposed as a higher level user function once it's implemented? Or will it be part a part of the edyn backend (such that users shouldn't tamper directly with it)?

What I've been thinking is that the kinematic contact solver will allow any kinematic entity to have this kind of procedural behavior. On top of that, a character controller will be implemented, which should be a higher level interface that creates the character as a capsule, applies gravity, allows walking, jumping and ducking.

[frutas-fruit]

[xissburg]

Cool :) I have not profiled raycasting nor stress tested it but given it uses the same trees that are used for broadphase (which are BVHs) I'd assume it's capable of handling large scenes if compiled with optimizations enabled.

[xissburg]

@tree786isback By the way, I have pushed a potential fix to the stuttering issue visible when using present_position and present_orientation. You can go back to using those for now and let me know if you still have any issues.

[frutas-fruit]

[xissburg]

Edyn was not-so-recently upgraded to EnTT 3.8.0. It was using EnTT 3.5.2 before. The upgrade wasn't very difficult, just tedious as a few things had to be changed in many places, such as the ones you mentioned. IIRC these are the things you'd have to change to make it compile with EnTT 3.5.2 or similar:

• entt::registry::emplace should be entt::registry::assign
• entt::to_integral should be entt::to_integer
• In newer versions of EnTT, views with a single type (e.g. registry.view<AABB>()) return a tuple with a single value in their get function. Previously, they'd return a reference to the component. There are places where you'll see things such as auto [manifold] = manifold_view.get(entity) which should be replaced by auto &manifold = manifold_view.get(entity);

[xissburg]

Regarding hashed string I am not sure since I don't think I use them. Another notable change is in the type id APIs also entt::registry::has was replaced by entt::registry::all_of/any_of. You can see the PR where the upgrade was made here https://github.com/xissburg/edyn/pull/55/files where you can see all relevant differences.

[xissburg]

You have to swap the arguments. The signals now take a registry first and an entity second, instead of entity then registry.

[xissburg]

No, that's not how it's done. You have to call get in the registry to get the tree_view, passing the entity you got in the parameter.

[frutas-fruit]

[xissburg]

Are forward_ray_offset, side_ray_offset and vertical_ray_offset in world space? I.e. did you apply the vehicle's rotation to them beforehand?

The usage of edyn::rigidbody_apply_impulse does not look right. The third parameter seems fine, as it would apply and impulse upwards, though I think you want to use the normal vector of the raycast result as the impulse direction. The fourth parameter must be the world space position of impulse application minus the position of the vehicle, i.e. it is a world space relative position vector which determines the impulse's leverage and how much torque it will generate. I imagine you want it to be ray_start - car_pos, assuming ray_start has been correctly calculated as a world space point.

[xissburg]

But here edyn::rigidbody_apply_impulse(registry, car_entity, edyn::vector3{0.0f, 9.0f, 0.0f}*delta_time, z_basis); you're passing z_basis in the fourth argument.

[frutas-fruit]

Ah sorry, you can ignore that code, it was an incorrect oversimplification of the more complex setup code I'm using. Here is the real code setup I've been doing before:

edyn::rigidbody_apply_impulse(reg, car_entity, ((length_delta*spring_damping)+(local_y_velocity_magnitude*viscous_damping)*local_y_velocity_sign)*dir_vec_y*delta_time, ray_start-(car_pos-vertical_ray_offset));

However I recently changed it to be something like this:

edyn::rigidbody_apply_impulse(reg, car_entity, ((length_delta*spring_damping)+(local_y_velocity_magnitude*viscous_damping)*local_y_velocity_sign)*dir_vec_y*delta_time, side_ray_offset + forward_ray_offset);

In any case, the fourth param should be always in local space, relative to the vehicle (as ray_start - car_pos would always give the relative offset, which I calculate as side_ray_offset + forward_ray_offset)

[xissburg]

Assuming side_ray_offset and forward_ray_offset are direction vectors in world space, that looks right to me.

[frutas-fruit]

[xissburg]

LoL! I actually don't know how that include got in there. I have removed it in this commit. Something with vscode inserting includes without my consent.

[frutas-fruit]

Ah I see!

[frutas-fruit]

[xissburg]

I cannot imagine anything besides an issue with the vehicle force calculation, as I haven't seen similar issues in other situations. Usually this could happen when an island is sleeping it wakes up. But that has been stable in the engine for a while. Perhaps you could check if the vehicle is sleeping when this happens.

[frutas-fruit]

I cannot imagine anything besides an issue with the vehicle force calculation

That makes sense. I've noticed that vehicle bounciness gets affected by framerate (I am applying delta time to the impulse calc though). Probably the only explanation is the decrease in framerate (due to 100's of rigid bodies eating up performance) is increasing delta time, which causes larger suspension impulses

[xissburg]

It is making sense to me now. A higher delta time will result in bigger impulses, and a bigger impulse will result in a greater change in velocity. This velocity will then be assigned to the rigid body and cause these vibrations. The right solution is to use an external system and have it all be calculated in the physics threads using the fixed delta time.

[xissburg]

I think that view could only be empty if the rigid body was created with presentation set to false in the rigidbody_def, which causes present_position/orientation to not be assigned. Make sure that's set to true. Have you tried using position and orientation instead?

[xissburg]

I'm not sure what you mean by updating the position in the external systems. Positions shouldn't generally be set manually.

[frutas-fruit]

I think that view could only be empty if the rigid body was created with presentation set to false in the rigidbody_def, which causes present_position/orientation to not be assigned. Make sure that's set to true. Have you tried using position and orientation instead?

Hmm I'll have to double check. And yeah I tried using the raw position and orientation but it's still empty

[frutas-fruit]

I'm not sure what you mean by updating the position in the external systems. Positions shouldn't generally be set manually.

I meant that I'm applying the new pos and orn to the mesh inside the external system. I am not touching or modifying the positions, but simply applying them to my 3D model inside of the extern system (hence what I meant by update)

[xissburg]

Sorry for not replying earlier but I just don't know how else I can help. I don't think I have enough information to get to any conclusion.

[frutas-fruit]

[Q] General benchmarks for edyn?

Do you have an idea of how many rigid bodies edyn is "designed" to handle at a comfortable framerate (e.g. 60fps)? I find that when I spawn over 100 rigid bodies (say ~170 or more), my fps gets a hit. That's partially due to rendering aspect (more meshes in the word), but was wondering what "maximum" ball-park limits edyn can handle to keep a steady-ish framerate? Have you been able to run simulations with, say 2000 rigid bodies, without tanking performance? I haven't done any serious benchmarking, but just curious to see general rigid body limits

[xissburg]

Edyn should not be causing your fps to drop due to a larger quantity of bodies and constraints, as the physics simulation is not being done in the main thread. If the fps is dropping, it must be something else. You can only tell if the physics simulation performance is degrading if objects start to slowdown. For example, in the first sample in Edyn Testbed which contains by default 125 boxes, when running in debug mode, if you pick a box from the bunch and pull it out, it will initially move slowly and as soon as it exits the big island of boxes, it starts moving fast again as it is now being simulated in a separate thread.

I haven't done much in terms of bench marking but you can try in the Edyn Testbed. I see that if I scale it up to 1000 boxes in the first sample, compiled with optimizations, things start to slow down (though the fps remains high). But that is largely because all boxes are stacked up and there are too many contact constraints. If you start to take the stack apart, things start to move faster as the contact constraints are destroyed.

[frutas-fruit]

Ok thanks for clarifying. It must be something on my end then, probably related to rendering more meshes when I spawn my rigid bodies

[frutas-fruit]

[Q] cone constraint parameters

I was looking into the cone constraint example in the testbed, but I don't understand what the following paramaters are:

        cone_con.frame = edyn::matrix3x3_columns(edyn::vector3_y, -edyn::vector3_x, edyn::vector3_z);
        cone_con.span_tan[0] = std::tan(edyn::to_radians(30));
        cone_con.span_tan[1] = std::tan(edyn::to_radians(60));
        cone_con.bump_stop_length = 0.3;

What do frame, span_tan[0], span_tan[1], and bump_stop_length define?

[xissburg]

See comments in cone_constraint.hpp. Let me know if you have further questions.

[frutas-fruit]

Glitchy collisions with static triangle_mesh terrain

I've made a crude model of a race track, and decided to test it out with the raycasted vehicle.

The problem is, the car falls through the road part very easily (bad collision), however it collides with the grassy terrain with no issues.

The collision mesh for the whole track + terrian is pretty high poly, at around ~33.5k verts / ~64k tris. I've done some optimizations to reduce poly count for the collision mesh, but there is definetely opportunity to reduce it further. But I don't get why the rigid body flashes through the road, yet is has no issues colliding with the grassy terrain part? They are all part of the same collision mesh (road+grassy terrain), and they are being loaded in as a cached binary (~8.5mb).

Any ideas what could be wrong?

[frutas-fruit]

Ok, think I've got it working as expected. I was using a lower poly road mesh for the collision (and higher poly as seen in GIF for rendering). The lower poly wasn't generated very well, as I used a decimate modifier, so it probably created an offset between the high poly renderable one and the lower poly collision mesh. Hence (I assume) why the car sinks in some areas

[frutas-fruit]

Although a question in my mind remains -- why does the road require thickness for correct collision, whereas the grassy terrain (which is equally made up of a flat planar mesh) doesn't? I.e. I could add thickness to the terrain, but it isn't needed as it collides well. But why does the road require thickness? Are lumped collision triangle meshes supposed to behave like that?

[xissburg]

Were the normals pointing upwards when the mesh had no thickness? Have you tried inverting them? Sometimes normals get messed up in Blender and you need to fix them using Recalculate Normals (ctrl+shift+N).

[frutas-fruit]

Ah sorry seems like the old road mesh (with no thickness) had incorrect normals as you mention. I thought they were correctly oriented, but seems like there was something wrong with that mesh. Apologies for that, it works fine with a thin road mesh now (with correct normals)! thanks 👍

[xissburg]

No worries, that's something that also gets me at times. The mesh normals are actually not used in collision detection, because it doesn't have triangle normals anyways... only vertex normals are exported. But that changes the winding order of vertices, which is what determines the orientation of normals when they're calculated using cross products in the engine. That's something we have to always watch out for before exporting: normal vectors and internal faces.

[frutas-fruit]

compound shape issues

Although I've asked this before, i'm still having issues to get certain convex shapes to work properly. I have a very simple convex mesh which is just a plain rectangular cuboid:

But it freaks out when I load it as a rigid body with a compound_shape:

I'm having difficulty debugging this behaviour, as some meshes seem to work better than others. And I don't know why that happens? Any ideas about this?

[frutas-fruit]

yeah, here is a slightly different one (i've been trying different iterations to see which one works best), as I made and discarded some older ones
collis.obj.zip

[frutas-fruit]

[xissburg]

Hmm ok

[frutas-fruit]

not sure what is going on with my raycasts, but they seem to hate the collision mesh i'm using

I don't think they're intersecting with the mesh now, but i need to figure out why it's so unstable with the new col mesh

[frutas-fruit]

I tweaked some force values and it's much more stable now, so it probably wasn't the collision mesh fault 😞 🍇 🍉

[frutas-fruit]

Trying to work with external systems

I'm trying to convert my raycasted system to be an external edyn system. I'm following the external_systems.cpp example in the testbed demo, and have a setup like this:

//HPP FILE
struct EdynCar{ //this is the external component
  ...
};

class RaycastedVehicle{
public:
registry* m_registry;

RaycastedVehicle(registry* reg);

update(); //this is the func that will be called in an external thread (i.e. the extern funct)
};

//CPP FILE
RaycastedVehicle::RaycastedVehicle(registry* reg): m_registry(reg){
    edyn::rigidbody_def car_col=edyn::rigidbody_def();
    car_col.kind=edyn::rigidbody_kind::rb_dynamic;
    (*car_col.material).friction=0.3f;
    (*car_col.material).restitution=0.6f;
    car_col.position = {1183.6f, 131.7f, 580.9f};
    // car_col.position = edyn::vector3{0.f};
    car_col.shape = edyn::compound_shape("../collision_mesh.obj");
    entity car_id = edyn::make_rigidbody(*m_registry, car_col);
    edyn::register_external_components<EdynCar>(*m_registry);
    edyn::set_external_system_pre_step(*m_registry, &RaycastedVehicle::update);
    m_registry->emplace<EdynCar>(car_id);
}

I.e. the external system is called RaycastedVehicle::update() and it is being passed the external component called EdynCar.
But I get errors when I compile:

error: cannot convert ‘void (RaycastedVehicle::*)()’ to ‘edyn::external_system_func_t’ 

I don't know how to fix it. Any ideas?

[frutas-fruit]

Thanks!

[xissburg]

You must not call edyn::update. That function has to be called in the main thread only.

[frutas-fruit]

Ok I see, thanks. I've noticed that it takes quite a while to compile after I introduced the external system. It hangs on 99% for a while (maybe >20 seconds), whereas without the extern system it might take less than 5 seconds. This is currently making it very tricky to edit the code and re-compile, as I usually tweak some LoC or variables, and quickly want to see results without having to wait >20 seconds every time. Any ideas if there is a solution to this?

[xissburg]

I face this issue as well. It's apparently due to the compilation of classes and functions with many template parameters. All external components are concatenated with internal components and passed to an instantiation of certain template classes and functions which will have as many as 50 parameters total. I still don't know how to improve the compilation performance...

[xissburg]

It should work in external systems as well. I have never tested it though 🙈

[frutas-fruit]

[xissburg]

I had not seen this post, as this place is becoming difficult to navigate. Perhaps you should create a new discussion for each question.

Indeed the raycast position you're sync'ing will not match that of the present transforms, since those are interpolated backwards to prevent jitter caused by the physics updates using fixed time steps. That's also true of the position of contact points for example. I think that for a raycast vehicle you only want to update the vertical position of the wheels though. The other axes should be fixed with respect to the vehicle body.