Hello,
after days experiment this great tool I've come with question ideas and suggestions ( If I'm allowed to do some)
So I'll started by the simpler question. Are you going to implement a box container ? If not, is it possible to use the one in xna framework ?
what are the value for the mass and the size ? I've really look at it but I don't understand how to add some physically simulated entities. I'm interested by the capsule. you told me it was a good shape for the character control. It could be good for ragdoll. I've just made one tonight, I was planning to add to a skinned character but I when I start tweaking I realise that I did not know how to get the orientation of each box I've created. I looked at some feature like get cross matrix, but I wasn't sure what was the use of it.
Is the capsule cost less cpu than a box ? I'm really concern by the frame rate because I'll maybe start some procedural animation for my fighting game.
Anyway I still learning a lot of thing and that's great. I hope, I'll have finish the camera this week end with a little level sample.
cheers
many questions from sueds
Re: many questions from sueds
The engine already includes a StaticGroup (in v0.4.0) which you can add boxes and other static entities to. This sounds similar to what you want from a box container. It doesn't explicitly support adding BoundingBox types, but its fairly easy to create an entity box based on a bounding box ( (min + max) / 2 for position, max.X - min.X for width, and so on). This system uses an internal accelerating structure, so it will be pretty quick.
Mass can be any value for physically simulated objects (as long as you stay away from 0 and infinity and you keep the masses of objects in your simulations on roughly the same order of magnitude). I like considering them to be kilograms, it keeps everything consistent. You can consider them to be any units that you'd like, as long as it is the same system for every object.
The capsule size, for example, is determined by a length and a radius; you can consider the capsule to be a line segment with a sphere that has had its center moved across the line segment. The length of the line segment and the radius of the sphere are the sizes referred to in the constructor. For other objects which have width, height, and length, these correspond to distances along the X, Y, and Z axes respectively. Similarly to the units used in mass, it doesn't really matter what you consider them as long as you're consistent. I like sticking to metric, so I think of them as meters usually.
Are there any other details that you think would be helpful for documentation (external or in the XML documentation)?
Capsules do indeed work fairly well in ragdolls. It might be a litle annoying right now to get the ragdolls working great though since v0.4.0 does not support pairwise intangibility (objects at a joint will be constantly colliding). If I have time, I'll try to work in a collision categories system and a pairwise intangibilty system for v0.5.0.
You can get the orientation of a body by looking at its orientation quaternion, I believe called "rotation" in v0.4.0. The rotationMatrix is also in there, representing the same data but in matrix form. These orientations transform the body from its configuration space- the way it was initially created, such as a capsule's line aligning with the Y axis- into world space, so they appear to roll around correctly.
In v0.5.0, the names and some access permissions have been reworked. Instead of rotation and rotationMatrix, they have been renamed to orientation and rotation. Orientation refers to the quaternion, rotation refers to the matrix. Setting the quaternion's value will automatically make all the necessary changes to properly rotate the object, and mofidications to the rotation matrix are disallowed (can only be read) as it is a value derived directly from the orientation.
Capsules and boxes have similar collision detection times, as they both use the same system. Capsules, being 'perfectly round,' can take a few more iterations in the detection system to get down to an acceptable margin of error, but it's not hugely significant. You might have some graphics speed issues using the built in defaults for capsules though, I triangulated them pretty heavily. In the DisplayCapsule initializeShape(), you can adjust the amount of triangles by changing the numSides value at the very beginning of the method.
Mass can be any value for physically simulated objects (as long as you stay away from 0 and infinity and you keep the masses of objects in your simulations on roughly the same order of magnitude). I like considering them to be kilograms, it keeps everything consistent. You can consider them to be any units that you'd like, as long as it is the same system for every object.
The capsule size, for example, is determined by a length and a radius; you can consider the capsule to be a line segment with a sphere that has had its center moved across the line segment. The length of the line segment and the radius of the sphere are the sizes referred to in the constructor. For other objects which have width, height, and length, these correspond to distances along the X, Y, and Z axes respectively. Similarly to the units used in mass, it doesn't really matter what you consider them as long as you're consistent. I like sticking to metric, so I think of them as meters usually.
Are there any other details that you think would be helpful for documentation (external or in the XML documentation)?
Capsules do indeed work fairly well in ragdolls. It might be a litle annoying right now to get the ragdolls working great though since v0.4.0 does not support pairwise intangibility (objects at a joint will be constantly colliding). If I have time, I'll try to work in a collision categories system and a pairwise intangibilty system for v0.5.0.
You can get the orientation of a body by looking at its orientation quaternion, I believe called "rotation" in v0.4.0. The rotationMatrix is also in there, representing the same data but in matrix form. These orientations transform the body from its configuration space- the way it was initially created, such as a capsule's line aligning with the Y axis- into world space, so they appear to roll around correctly.
In v0.5.0, the names and some access permissions have been reworked. Instead of rotation and rotationMatrix, they have been renamed to orientation and rotation. Orientation refers to the quaternion, rotation refers to the matrix. Setting the quaternion's value will automatically make all the necessary changes to properly rotate the object, and mofidications to the rotation matrix are disallowed (can only be read) as it is a value derived directly from the orientation.
Capsules and boxes have similar collision detection times, as they both use the same system. Capsules, being 'perfectly round,' can take a few more iterations in the detection system to get down to an acceptable margin of error, but it's not hugely significant. You might have some graphics speed issues using the built in defaults for capsules though, I triangulated them pretty heavily. In the DisplayCapsule initializeShape(), you can adjust the amount of triangles by changing the numSides value at the very beginning of the method.
Re: many questions from sueds
hi,
If I understand well I just have to use orientation quaternion. I haven't seen getOrientation or something like that ... I was trying to add it to a character even if I haven't tried yet the animation stuff on xna, but I was wondering that I would need the rotation to deform properly the bone. I've not tweak it yet since I'm working on the camera collision. But it's really long to set up boxes to create recreate the warehouse I've made on lightwave.
about thing I do not understand is the use of physically simulated. I mean when I define a variable I do not know what to do with it after. So I cannot add any capsule.
I have not try the tool box and the other feature so I cannot say anything about it. Definitely next week. I'll be further on my experiment.
If I understand well I just have to use orientation quaternion. I haven't seen getOrientation or something like that ... I was trying to add it to a character even if I haven't tried yet the animation stuff on xna, but I was wondering that I would need the rotation to deform properly the bone. I've not tweak it yet since I'm working on the camera collision. But it's really long to set up boxes to create recreate the warehouse I've made on lightwave.
about thing I do not understand is the use of physically simulated. I mean when I define a variable I do not know what to do with it after. So I cannot add any capsule.
I have not try the tool box and the other feature so I cannot say anything about it. Definitely next week. I'll be further on my experiment.
Re: many questions from sueds
PhysicallySimulated is an interface inherited by all of the Phys prefixed entities, such as PhysBox and PhysSpheres. You could use it to create an entity like so:
PhysicallySimulated box1 = new Phys...
However, you'd have to cast it to an Entity type (the Phys..., or the type (Box), or Entity) to add it to the space. Generally it's easier just to use:
PhysBox box1 = new PhysBox(...);
That way you can do whatever you'd like with it.
In v0.5.0 the PhysicallySimulated interface will be removed (as I mentioned in another thread, static and dynamic objects are being merged). It was redundant and caused confusion like I believe you are encountering with the lack of orientation references in the PhysicallySimulated type. All of those (position, orientation, etc) are contained within Entity types.
In regards to the time expense of created boxes to match level geometry, it is a problem- further on down the road (beyond v0.5.0, probably beyond v1.0.0) I'd like to create a physics editor tool for it that would expedite the process. It would be partially integrated into a level editor used internally for game development, but it's a bit early to guess exactly what will be included.
PhysicallySimulated box1 = new Phys...
However, you'd have to cast it to an Entity type (the Phys..., or the type (Box), or Entity) to add it to the space. Generally it's easier just to use:
PhysBox box1 = new PhysBox(...);
That way you can do whatever you'd like with it.
In v0.5.0 the PhysicallySimulated interface will be removed (as I mentioned in another thread, static and dynamic objects are being merged). It was redundant and caused confusion like I believe you are encountering with the lack of orientation references in the PhysicallySimulated type. All of those (position, orientation, etc) are contained within Entity types.
In regards to the time expense of created boxes to match level geometry, it is a problem- further on down the road (beyond v0.5.0, probably beyond v1.0.0) I'd like to create a physics editor tool for it that would expedite the process. It would be partially integrated into a level editor used internally for game development, but it's a bit early to guess exactly what will be included.
Re: many questions from sueds
I started looking at a physic editor but I didn't seems so complicated to set. My problem was win forms, a way too slow to handle physic and wysiwyg editor. xna lacks of some kind of killer aps. But It's nice to see people working on such awesome things. Are you working alone or with a dev team ?
Re: many questions from sueds
I'm alone in regards to the physics side of things, but we've got a um... small 'team', I suppose you could call it, right now. The only other member of this team is working on some other things for unannounced projects 
Re: many questions from sueds
I've just noticed that I wasn't working on the latest version the reason I coudn't not find the capsule, but I'm having a really bad time the new display method. I prefer the old one for two reason. The purpose of this display method is to debug ? On my laptop the frame rate drop to 15 fps from 60 on the older version. the second reason is that you choose to use cs to store your physics class instead of dll. As for the first reason the debugging is the purpose of the display method. So the cs aren't really necessary since we don't really need to tweak it.
I'll stick to the first 0.4 version since I cannot find what's slowing down my laptop.
With your "team" are you building dev tool or your own game ?
keep it up
I'll stick to the first 0.4 version since I cannot find what's slowing down my laptop.
With your "team" are you building dev tool or your own game ?
keep it up
Re: many questions from sueds
Most of the old display method is still present (DisplayObject has a draw(Effect effect) method), much of the complication in the system is in the newer/faster GPU instancing method used by default. There's also a slightly more CPU intensive (but easier on the GPU) CPU-instancing method which can be forced (passing false in for useShaderInstancing in the constructor).
The GPU instancing method vastly improves my framerates on simulations with many objects (like broad phase stress test, or rest state). In the old, non-instancing method, the rendering would actually overtake the physics as the main CPU hit, which complicated things.
If the GPU is a bottleneck, decreasing the triangle counts should help, and if that fails, switching to using CPU instancing could help as well.
The main reason I moved the drawing out of the .dll is that it is conceptually separate from the engine and I wanted to avoid bundling the engine itself with extra, fundamentally unrelated data. In addition, there could be (and have been) tweaks that others may want to make that I could not foresee, and it could act as a helpful learning tool for someone seeking additional examples on instancing (though the clarity of code on a whole, given the redundant systems, might make that a bit more difficult than necessary).
Do you happen to know what graphics capabilities that laptop has? It seems a bit odd that it would resort to using SM3/GPU instancing yet doesn't have enough power to support a relatively cheap graphics system. That is, if it is even using the GPU instancing method; if it's not, then I'm even more confused because the alternative CPU instancing method is less graphically expensive than GPU instancing and less CPU intensive than the draw calls per object used in v0.3.0.
The project we're working on is a game, but we think having easy to use development tools is a very good investment. And, if it draws more people to the game due to custom content, even better
EDIT:
I just realized you said that you'll stick with the first version of v0.4, does it actually run better than v0.4.1? If so, that is very strange, as the only meaningful thing that I knowingly changed was enable backface culling- something that should help, not hurt.
The GPU instancing method vastly improves my framerates on simulations with many objects (like broad phase stress test, or rest state). In the old, non-instancing method, the rendering would actually overtake the physics as the main CPU hit, which complicated things.
If the GPU is a bottleneck, decreasing the triangle counts should help, and if that fails, switching to using CPU instancing could help as well.
The main reason I moved the drawing out of the .dll is that it is conceptually separate from the engine and I wanted to avoid bundling the engine itself with extra, fundamentally unrelated data. In addition, there could be (and have been) tweaks that others may want to make that I could not foresee, and it could act as a helpful learning tool for someone seeking additional examples on instancing (though the clarity of code on a whole, given the redundant systems, might make that a bit more difficult than necessary).
Do you happen to know what graphics capabilities that laptop has? It seems a bit odd that it would resort to using SM3/GPU instancing yet doesn't have enough power to support a relatively cheap graphics system. That is, if it is even using the GPU instancing method; if it's not, then I'm even more confused because the alternative CPU instancing method is less graphically expensive than GPU instancing and less CPU intensive than the draw calls per object used in v0.3.0.
The project we're working on is a game, but we think having easy to use development tools is a very good investment. And, if it draws more people to the game due to custom content, even better
EDIT:
I just realized you said that you'll stick with the first version of v0.4, does it actually run better than v0.4.1? If so, that is very strange, as the only meaningful thing that I knowingly changed was enable backface culling- something that should help, not hurt.
Re: many questions from sueds
hi, I'm using a laptop with 2048 of ram and video card nvida serie 6.
you are true about the instancing method, I was just looking at it right now ! but you are using vertex so it didn't help so much. I'm trying to make a simple mesh match its movement to a simple PhysBox. So when I try to use quaternion or rotation matrix but it don't work directly so the problem I have is I don't know how to do.
Matrix[] t2 = new Matrix[box.rotation];
crate.CopyAbsoluteBoneTransformsTo(t2);
is not working. I try to change using rotation matrix and it didn't help. Is quite hard to figure out which direction to take. Do you think it's possible to attach a mesh to a ragdoll in the current version of BepuPhysics ?
About the render the dll, I'm talking for people aren't programmers but just hobbyist, It can be scary to see many different file for one application. I mean to figure out what's necessary of not sometimes is really long. I learn most of the game programming by tweaking and I prefer the simplest to start with and then add more and more stuff. But it still interesting.
Anyway I'm glad you let a sort of draw system. So you told me that the instancing was by default ? it's sad because I really wanted to use the capsule. maybe I should use bounding boxes.
you are true about the instancing method, I was just looking at it right now ! but you are using vertex so it didn't help so much. I'm trying to make a simple mesh match its movement to a simple PhysBox. So when I try to use quaternion or rotation matrix but it don't work directly so the problem I have is I don't know how to do.
Matrix[] t2 = new Matrix[box.rotation];
crate.CopyAbsoluteBoneTransformsTo(t2);
is not working. I try to change using rotation matrix and it didn't help. Is quite hard to figure out which direction to take. Do you think it's possible to attach a mesh to a ragdoll in the current version of BepuPhysics ?
About the render the dll, I'm talking for people aren't programmers but just hobbyist, It can be scary to see many different file for one application. I mean to figure out what's necessary of not sometimes is really long. I learn most of the game programming by tweaking and I prefer the simplest to start with and then add more and more stuff. But it still interesting.
Anyway I'm glad you let a sort of draw system. So you told me that the instancing was by default ? it's sad because I really wanted to use the capsule. maybe I should use bounding boxes.
Re: many questions from sueds
All of the information you'd need is available (geometry, position, rotation) to create a ragdoll now; it should be possible.
I'm afraid I can't be of much help yet in figuring out how to get a mesh bound to a set of objects, all I can say is make sure that the correct transforms are being applied (position and rotation etc.).
This is exiting the realm of the physics engine a bit- you probably could find someone who knows more about it by posting on the creators club forums (forums.xna.com). I'll be watching if you do make a post, just in case they ask anything specific about the engine itself that you might not know. It comes down to taking the data that you do have (position and orientation) and giving it to the mesh in the way that it wants, something that I'm not familiar with yet.
The only problems you'll encounter on the physics side in v0.4.0 is the lack of collision categories (like I mentioned earlier) and that ball socket joints can't yet be restricted rotationally, so your knees and elbows can flop around a bit more than realistically. The collision categories should make it into v0.5.0, but to get the rest out in a timely manner there's a good chance that I'll need to bump the rotational/motion limits for joints to v0.6.0. This isn't a game-breaker, but it will look nicer with limits
As for the instancing, yes, it is on by default, but you can turn it off very easily (useShaderInstancing set to false in the constructor). The CPU instancing should be faster in every way compared to v0.3.0's renderer, even with a less-than-great GPU. The other slowdown would be the triangle counts on the objects, since I did increase their detail significantly. Every DisplayObject type has a initializeShape() method, and for the heavily triangulated objects, a "numSides" or similarly named set of variables can be changed to reduce the detail. With CPU instancing/reduced triangle counts, the graphics performance should be better than v0.3.0 regardless of the system.
I'm afraid I can't be of much help yet in figuring out how to get a mesh bound to a set of objects, all I can say is make sure that the correct transforms are being applied (position and rotation etc.).
This is exiting the realm of the physics engine a bit- you probably could find someone who knows more about it by posting on the creators club forums (forums.xna.com). I'll be watching if you do make a post, just in case they ask anything specific about the engine itself that you might not know. It comes down to taking the data that you do have (position and orientation) and giving it to the mesh in the way that it wants, something that I'm not familiar with yet.
The only problems you'll encounter on the physics side in v0.4.0 is the lack of collision categories (like I mentioned earlier) and that ball socket joints can't yet be restricted rotationally, so your knees and elbows can flop around a bit more than realistically. The collision categories should make it into v0.5.0, but to get the rest out in a timely manner there's a good chance that I'll need to bump the rotational/motion limits for joints to v0.6.0. This isn't a game-breaker, but it will look nicer with limits
As for the instancing, yes, it is on by default, but you can turn it off very easily (useShaderInstancing set to false in the constructor). The CPU instancing should be faster in every way compared to v0.3.0's renderer, even with a less-than-great GPU. The other slowdown would be the triangle counts on the objects, since I did increase their detail significantly. Every DisplayObject type has a initializeShape() method, and for the heavily triangulated objects, a "numSides" or similarly named set of variables can be changed to reduce the detail. With CPU instancing/reduced triangle counts, the graphics performance should be better than v0.3.0 regardless of the system.
Re: many questions from sueds
I've just manage to add a crate to physic box.
It was tough but I'll share the code to save up some time to some people.
void DrawCrate(Model model, Matrix w)
foreach (ModelMesh mesh in model.Meshes)
{
foreach (BasicEffect be in mesh.Effects)
{
be.Projection = perspective;
be.View = view;
be.World = w;
}
mesh.Draw();
}
}
Vector3 pos;
void drawC()
{
pos = box.getPosition();
Matrix mov = Matrix.CreateTranslation(pos);
Matrix rot = bx.rotationMatrix;
DrawCrate(crate, Matrix.CreateScale(15f)* rot*mov );
}
then in the draw method
drawC();
the box represent the physic box. It remains some problem. I'm going to ask on forum.xna because I'm not using the bone feature the level move in a diferent way than the crate. I would like to ask you again if you where storing the position data like in xna framework or with different value ? Because it may be the reason.
anyway I'm going too sleep it's the morning here in london. Thanks again for help me so much.
It was tough but I'll share the code to save up some time to some people.
void DrawCrate(Model model, Matrix w)
foreach (ModelMesh mesh in model.Meshes)
{
foreach (BasicEffect be in mesh.Effects)
{
be.Projection = perspective;
be.View = view;
be.World = w;
}
mesh.Draw();
}
}
Vector3 pos;
void drawC()
{
pos = box.getPosition();
Matrix mov = Matrix.CreateTranslation(pos);
Matrix rot = bx.rotationMatrix;
DrawCrate(crate, Matrix.CreateScale(15f)* rot*mov );
}
then in the draw method
drawC();
the box represent the physic box. It remains some problem. I'm going to ask on forum.xna because I'm not using the bone feature the level move in a diferent way than the crate. I would like to ask you again if you where storing the position data like in xna framework or with different value ? Because it may be the reason.
anyway I'm going too sleep it's the morning here in london. Thanks again for help me so much.
Re: many questions from sueds
The position and rotation format/storage is consistent with the XNA framework; there shouldn't be any 'translation' problems so to speak.
Anyway, good 'night'
Anyway, good 'night'
Re: many questions from sueds
I tried to tweak my code and the problem remains the same. If someone know how to transform a mesh vertices following a a physic object it would be thankful for this.
I'm stuck to the collision detection for now so maybe I'll wait until the next version.
cheers
I'm stuck to the collision detection for now so maybe I'll wait until the next version.
cheers
Re: many questions from sueds
I just looked again my post and I made a mistake. I was not using the v.03 but the v.04. The first one you release not the second one. I test a little bit some future of your engine and the orientation translation is really problematic. I didn't get how to make mesh match a physic primitive. Is it a bug or is it my fault.
cheers
cheers
Re: many questions from sueds
The position/rotation data retrieved from the engine is valid; all that should be necessary for aligning a mesh with a physical object is rotating the mesh (using the rotation matrix or quaternion) and translating it into world space (using its position). On the physics engine side of things, everything should be ok.
One possible problem would occur if the mesh isn't designed in local space. If this was the case, performing the above transformations would result in a location floating some distance away from the actual position.
In your attempts to get it to work, how was the mesh behaving (crashing, floating off to the side of where it should be, etc.)?
One possible problem would occur if the mesh isn't designed in local space. If this was the case, performing the above transformations would result in a location floating some distance away from the actual position.
In your attempts to get it to work, how was the mesh behaving (crashing, floating off to the side of where it should be, etc.)?