BEPUphysics

Hi,
I hope my question is simple I would support a plane/box on rays, and I have no idea. I tried to apply impulse when one of the corners of the table is to close to the ground, but it looked like it was floating on water.
What I want to do is to raytest from each corner of the plane, and I don't want to use two entity joints. So how can I fake legs of the table with rays like that?

I'm not exactly clear on the usage; if creating a compound body where the table top and table legs are part of the same entity could work, I'd recommend doing it that way.

If you don't want the table legs to interact with all objects, the collision rules of the subbodies can be modified.

If a compound body is not acceptable, then using a Vehicle with stiff suspensions might do the trick. Each wheel is a ray cast anyway.

I am just experimenting. What I already achieved is perfect for wipeout type of game I also saw that joints constructors accepts null as entityA or entityB parameters, what's the reason for that and what we get? I also would like to know how bepu creates mobileMesh from model. Does it make a convex hull out of it (I saw this in some other physics engines) or does it simplify it a bit?
Sorry for so much questions (especialy that they have almost nothing in common, I am just uber curious )

I also saw that joints constructors accepts null as entityA or entityB parameters, what's the reason for that and what we get?

Passing in null as a connection connects to a special 'world entity,' which is actually just a kinematic sphere sitting at (0,0,0) but not added to the space. The actual entity instance is located in the TwoEntityConstraint.WorldEntity field. You can do something similar manually by connecting the joint to an unmoving kinematic entity.

Using this 'world entity' requires some care, though. You have to be aware of the constraint's organization; a basis of some kind is usually attached to connection A and some kind of measurer is attached to connection B. Because of this, the behavior of the constraint can change depending on which connection is null. Also, the default position at (0,0,0) can result in some very long lever arms which can cause stability issues with some configurations.

I also would like to know how bepu creates mobileMesh from model. Does it make a convex hull out of it (I saw this in some other physics engines) or does it simplify it a bit?

The mobile mesh does not perform any simplification; it assumes all content processing has been performed beforehand. The MobileMesh triangles are exactly the triangles passed into the constructor. It is not a convex hull; it will perform true triangle-level collision detection.

Because of this, MobileMeshes are generally slower than simpler representations. Using a ConvexHullShape instead of a MobileMeshShape is a common way to save some time if the concavity of the shape doesn't really matter. Simplifying the source model helps too in any case.

If the concavity is important, you can get better performance than the MobileMeshShape by approximating the shape with a set of simpler primitives and putting them together in a CompoundShape. Creating a CompoundShape of multiple ConvexHullShapes is common; you could use a convex decomposition algorithm to do this automatically in the content build tools (there is not a convex decomposition algorithm available in the engine at the moment). An even simpler represention could be a set of boxes, spheres, and other very simple primitives bundled together in a CompoundShape which approximate the concavity.

Norbo wrote: Passing in null as a connection connects to a special 'world entity,' which is actually just a kinematic sphere sitting at (0,0,0) but not added to the space.

Thanks, my curious mind is satisfied

Norbo wrote: The mobile mesh does not perform any simplification; it assumes all content processing has been performed beforehand. The MobileMesh triangles are exactly the triangles passed into the constructor. It is not a convex hull; it will perform true triangle-level collision detection.

It's good to know that modeling physical proxies weren't for nothing. Still I am very impressed with your implementation, because where your engine handles it at 60 fps no problem, others where crying at ~5fps with dynamic meshes (i did some tests with higher poly count objects).

As for the table I looked at earthquake demo, it had all what i needed to help me

Also I would like to know if bepu would be good for paricles(just using Sphere class for particle) and how many particles would be safe to run smoothly(excluding time for graphics)?

Also I would like to know if bepu would be good for paricles(just using Sphere class for particle) and how many particles would be safe to run smoothly(excluding time for graphics)?

If your particles are supposed to be rigid spheres that impact gameplay, it may be a good fit On a modern processor, assuming the particles tended to float rather than fall into a big pile, I'd estimate you could get a few thousand such spheres running without much trouble. (Maybe more than 10000 if you spent most of the CPU budget on it and there weren't a lot of interactions. My 3770K can handle 15625 boxes flying around in the PlanetDemo at around 10-16 ms per update despite there being 27500 collision pairs at one point.)

On the other hand, if you don't want rigid spheres, then using a sphere entity is both more expensive than necessary and not a very good fit for the job. If the particles don't influence gameplay meaningfully, it would be better to just do a simple particle simulation on the GPU. That would handle orders of magnitude more particles.

Norbo wrote: I'd estimate you could get a few thousand such spheres running without much trouble. (Maybe more than 10000 if you spent most of the CPU budget on it and there weren't a lot of interactions.)

Thats more than I will need

Norbo wrote: If the particles don't influence gameplay meaningfully, it would be better to just do a simple particle simulation on the GPU. That would handle orders of magnitude more particles.

I am starting a half year GPU programming course in a month, so I will skip this option for now ( As i remember part of this course also includes tons of particle simulation on cuda).

I also would like to know if Vehicle class implement weight transfer? I know that I can set mass center for the object. Does the weight transfer influence grip in vehicle class? (for instance, when we are breaking from high speed the front tires gain more grip due to weight shift) Or do i have to do it myself?

Does the weight transfer influence grip in vehicle class? (for instance, when we are breaking from high speed the front tires gain more grip due to weight shift)

Yup.

Wow, that is awesome
Less work for me Thanks for all the help, realy appreciate this