Thread: Re: [brlcad-devel] [ESA SOCIS] Question about the Celestial mechanics particle system
Open Source Solid Modeling CAD
Brought to you by:
brlcad
From: brlcad <br...@ma...> - 2011-07-20 18:30:37
|
On Jul 20, 2011, at 11:06 AM, Abhijit Nandy <abh...@gm...> wrote: ok, I get it. I tried the tire wizard today and the amount of detail shown with just the default command is incredible ! Yeah, tire is pretty awesome. So how are plugins compiled in Linux and Windows ? Exactly the same, LIBGED. The source code is written portably and compiled using CMake. So this associates the createWheel variable directly with the boolean value in the checkbox of the TireWizard dialog ? Basically, yep. So when the user run a command say "runphysics 20", then through Tcl the proper C++ function can be called with the parameters like time steps(20) passed in ...[snip]... The function that will actually create and run the physics simulation will be something like int ged_runphysics(struct ged *gedp, int argc, const char *argv[]) That is exactly the notion I had in mind. If you focus on implementing a command first, the problem is simplified. Now there are 2 ways of proceeding after this function gets called : 1. Bullet maintains a physics world(in an object of type btDiscreteDynamicsWorld) and objects can be added/removed to/from it during Archer's run. This would require a notification to the C code when objects get created in Archer. For a sphere, the appropriate sphere shape can immediately be added in Bullet's physics world. For more complex shapes like tires or tanks, a low resolution triangle mesh can be added(collisions would not need a very high resolution mesh). However this would require Bullet's physics world information to persist between functions calls from Tcl. That doesn't sound like a workable approach. We don't solely deal with mesh geometry. Maintaining a parallel geometry scene (in Bullet or otherwise) would only work if their system allows surrogate handles, like bounding boxes. Similarly, as there are NO explicit surfaces for some geometry, there exists no boundary for Bullet to perform collision detection -- that has to also happen in our code, not theirs. So there needs to be some way to specify or override collision detection so we can use our library to evaluate. Therefore I can keep the variables in global scope in the C code in a file like tire.c. So can such a notification system be setup where objects created, are immediately conveyed to the C code. The physics world would need to be kept in sync with the objects present in Archer's world(or scenegraph/simulation..I am not sure what its called yet :) ). This would allow the simulation to be run at any time with the current set of objects in Archer. That sounds pretty undesirable to me. Commands shouldn't be stateful. I'd rather build the scene up on the fly when the command is run, but then that gets back to my first point -- that we don't have meshes that can be passed over to a physics engine anyways. For example, if someone makes a sphere, it's just a point and a radius. There is no mesh. Sure we can calculate a mesh on the fly, but it's resolution-dependent (i.e., not at all accurate until you have millions of faces) and perhaps trivial for a sphere but not at all trivial for our 20+ other primitive shapes. 2. The other way is to setup and run the simulation when the user initiates it through a command. So the Tcl code notifies the C code about the objects to be added after the command is entered. The dimension of each object present in Archer would have to be conveyed and then the simulation steps can be done. Sounds better, but there's still the issue of how Bullet (or ODE or [insert_engine_here]) handle geometry and collisions. In both cases I am guessing the user would want to see the objects actually move in Archer as the physics progresses, so there must be some way to update the position of objects in the Archer GUI/scenegraph in realtime. I'd start simple. The command updates the position of objects for a specified timestep. For the GUI, it could simply call the command over and over for smaller timesteps in a loop, so it can animate the result. As a basic starting case I am going to try and implement the Bullet "Hello world" simulation in Archer to see if all parts work. It simply adds a sphere and allows it to fall under gravity. This can be the first milestone :) http://www.bulletphysics.org/mediawiki-1.5.8/index.php/Hello_World Sounds like a good plan. They key, however, will be getting it to work without creating anything more than bounding boxes or bounding spheres. Then, if I understand Bullet correctly, you'll just need to specify your own collision detection handler instead of calling btDefaultCollisionConfiguration() Cheers! Sean |
From: brlcad <br...@ma...> - 2011-07-20 22:34:09
|
On Jul 20, 2011, at 03:46 PM, Abhijit Nandy <abh...@gm...> wrote: So basically the physics engine’s role in this case is limited to detecting that objects overlap using their AABBs (axis aligned bounding boxes) or bounding spheres ? Correct. Either a single bounding volume or a hierarchy of bounding volumes. Yes I understand about the absence of meshes. So I guess the geometry information about each primitive shape has to be used e.g.. for a tire, its radius, width etc. has to be used for accurate collisions. Yeah I agree that commands should not be stateful. So the scene can be built up on the fly. Does Archer maintain a database from where the scene information can be got ? The information for the currently open .g file is stored within a struct ged object that is passed to all of the ged_command() functions. From there, you have access to the entire .g as well as all geometry objects that are currently being displayed. Yes I agree. So by the GUI calling the command over and over , you mean the Tcl code will repeatedly call the C function in a loop to animate the object ? Basically, yes. So each time the Tcl code calls the C function, : 1. the scene is read from Archer's database(or list of objects), effectively a list of objects 2. the scene is created in the physics engine in simplified form, AABBs 3. the forces are applied and position updated for the passed time steps 4. if any contacts occur then the custom collision handler gets called to accurately deal with the collisions. Exactly, our gqa and rtcheck tools are examples that perform precise collision detection. I am guessing that objects can be translated and rotated to the proper position using Archer commands, so these commands can be used in Tcl to position the object once the C function returns the list of new updated positions for the objects in the scene(lists should be possible to communicate back to Tcl). Alternatively perhaps objects in Archer can be directly rotated and translated to their resulting position from C code. Using LIBGED commands (which are available in Archer), but yes. In fact, the repositioning pretty much happens for free since once the objects are modified by LIBGED, they'll get redrawn automatically in their new position by a command wrapper. Cheers! Sean |
From: Abhijit N. <abh...@gm...> - 2011-07-20 23:01:38
|
> Exactly, our gqa and rtcheck tools are examples that perform precise > collision detection. ok. So good to know that tools exist for doing accurate collision between the 20+ primitives, then I guess there is no need to write them from scratch and I can try calling them in the collision handler while passing them the ged struct. Regarding compiling libged to add a new plugin, I guess the process is to run CMake first to create a Makefile in /src/libged After that something like ./configure > make > make install ? I guess only compiling libged should do. Also are there any particular options to be set in CMake ? > Exactly the same, LIBGED. The source code is written portably and > compiled using CMake. Or do I need to type in make LIBGED or something similar ? Thanks, Abhijit |
From: Christopher S. M. <br...@ma...> - 2011-07-25 04:06:42
|
On Jul 20, 2011, at 7:04 PM, Abhijit Nandy wrote: > ok. So good to know that tools exist for doing accurate collision between > the 20+ primitives, then I guess there is no need to write them from scratch > and I can try calling them in the collision handler while passing them the > ged struct. The means to detect interference exist, but a function will still need to be written to perform the detection in a clean manner given an arbitrary model. This could be as simple as refactoring the rtcheck tool or (more complex) refactoring gqa into library API. Cheers! Sean |
From: Abhijit N. <abh...@gm...> - 2011-07-20 19:43:37
|
> I'd rather build the scene up on the fly when the command is run, but then > that gets back to my first point -- that we don't have meshes that can be > passed over to a physics engine anyways. For example, if someone makes a > sphere, it's just a point and a radius. There is no mesh. Sure we can > calculate a mesh on the fly, but it's resolution-dependent (i.e., not at > all accurate until you have millions of faces) and perhaps trivial for a > sphere but not at all trivial for our 20+ other primitive shapes. Right I understand. Yeah most physics engines support contact callbacks to simply detect if 2 bodies are touching using a close approximation of their shape. The detailed collision can then be handled by a custom collision handler. So basically the physics engine’s role in this case is limited to detecting that objects overlap using their AABBs (axis aligned bounding boxes) or bounding spheres ? > Commands shouldn't be stateful. I'd rather build the scene up on the fly > when the command is run, but then that gets back to my first point -- that > we don't have meshes that can be passed over to a physics engine anyways. > For example, if someone makes a sphere, it's just a point and a radius. > There is no mesh. Sure we can calculate a mesh on the fly, but it's > resolution-dependent (i.e., not at all accurate until you have millions of > faces) and perhaps trivial for a sphere but not at all trivial for our 20+ > other primitive shapes. Yes I understand about the absence of meshes. So I guess the geometry information about each primitive shape has to be used e.g.. for a tire, its radius, width etc. has to be used for accurate collisions. Yeah I agree that commands should not be stateful. So the scene can be built up on the fly. Does Archer maintain a database from where the scene information can be got ? >I'd start simple. The command updates the position of objects for a >specified timestep. For the GUI, it could simply call the command over and >over for smaller time steps in a loop, so it can animate the result. Yes I agree. So by the GUI calling the command over and over , you mean the Tcl code will repeatedly call the C function in a loop to animate the object ? So each time the Tcl code calls the C function, : 1. the scene is read from Archer's database(or list of objects), 2. the scene is created in the physics engine 3. the forces are applied and position updated for the passed time steps 4. if any contacts occur then the custom collision handler gets called to accurately deal with the collisions. I am guessing that objects can be translated and rotated to the proper position using Archer commands, so these commands can be used in Tcl to position the object once the C function returns the list of new updated positions for the objects in the scene(lists should be possible to communicate back to Tcl). Alternatively perhaps objects in Archer can be directly rotated and translated to their resulting position from C code. Thanks, Abhijit |