English
资源说明：brlcad
Index: src/libged/simulate/README.txt =================================================================== --- src/libged/simulate/README.txt (revision 0) +++ src/libged/simulate/README.txt (revision 0) @@ -0,0 +1,26 @@ +There were a series of issues I came across while realizing the Mged Simulation so I started working on fixing them. Some of the issues I encountered where : + - the cube was penetrating the surface of the ground plane, tilding one side + - when I translated the same simulation in meter units then the simulation got aborted and a large number of steps, like 1000 steps wasn't making a real difference in the simulation, the cube didn't seem to drop closer to the ground + - the mass of the cube was increasing during the simulation. +To solve those problems I first looked in the bullet logic. + +1. Checking if the bullet logic works as it is supposed to: + + - in the simphysics.cpp source file is a "run_simulation()" function, we replace everything that is inside that function with the code from the "Hello World!", bullet tutorial - http://bulletphysics.org/mediawiki-1.5.8/index.php/Hello_World . We run the "simulate 1" command on any database file, we really don't care what the geometry in the said file it is, we can use the Mged simulation file. We don't care what the geometry is because in the run_simulation() function we create our own physics world - consisting of a ground plane and a sphere that falls to the ground. If everything works properly then we get the same result as the one in the "Hello World!" tutorial. + - the "dynamicsWorld->stepSimulation(1/60.f,10), line 535 in run_simulation() can be replaced with "step_physics(dynamicsWorld)", it does the same thing, steps into the simulation, but we want to see if we get the same output as before trying to tie the "Hello World!" tutorial to our existing code. We also comment out all the printing in the step_physics() function, otherwise we would get a segmentation fault when trying to run the "simulate" command. The segmentation fault will be due to the sim_params structure. Here is what the simphysics.cpp will look like paste.ubuntu.com/1253297/. + +So far we checked if the bullet logic works and the answer it is, yes it does work. Now we will revert back to the code from run_simulation(). + +The way the simulate command is working is like this : + - we add the objects to the bullet dynamic world, do one step of the simulation, get the transforms in the sim_params structure, then clear out everything and repeat. The simulation_params structure contains the simulation parameters, such as number of rigid bodies, the head node of the linked list containing the bodies and time/steps for which the simulation will be run. + - the simulate command loads everything that needs to be loaded in the simulation_params structure, then put it into the bullet dynamics world, run the required number of steps, grab the transforms at the end of each step from bullet, put it into sim_params, only the last transforms remain in the sim_params structure. The sim_params is then accesed in libged, to read the transforms and update the shapes in mged. You are interested in the initial position of the geometry when you start your simulation, you don't want to save all the intermediate steps your geometry finds itself during the simulation only the final state, you save it and then pass it to libged. + - in simulate.c in function int ged_simulate(), there's the main loop of the simulation where we are stepping through the simulation for the number of steps required. Here we are calling the run_simulation() function from simphysics.cpp. The bullet world is being recreated for every step of the simulation. + +When "simulate n" it's called, then ged_simulate() gets called. ged_simulate() adds the regions in the .g file using add_regions(), every region gets its own node in the list of struct rigid_body nodes, the head of this list is stored in sim_params, in struct rigid_body *head_node (see simulate.h). After that we get the main loop of the simulation, in the loop we create a combination representing the regions in their new positions, in a comb called sim.c and we keep a copy of all the regions being simulated but with the applied transforms as they are returned by bullet. This is to prevent modifying the original regions and their locations, so sim.c gets created in recreate_sim_comb(). After that we call run_simulation(), which only scans the list passed in sim_params and adds the objects whos information is present at each node. The number of nodes is the same as the number of regions being simulated and also the same as the number of rigid bodies inserted in the simulation. The ground plane has a fixed name "sim_gp.r", and in simphysics.cpp, add_rigid_bodies() we identify this name and add the coresponding static object. In run_simulation() we create the simulation world from scratch every time, we add the objects, run the simulation for just one step and get back the transforms in sim_params, then delete the bullet simulation stuff, dynamics world, collision shape. We do this to support collision for BRL-CAD's arbitrary shapes, like arbn that can not be created directly in bullet, bullet having only a limited number of primitives - like sphere, cone, cylinder, cube and some others - so we have to run the simulation one step, then get back the transforms into mged, hit the overlapping regions with rays, using the librt library - this way we get the exact contact points and penetrations information, put this info in the sim_param structure for the next iteration. If we would run the loop from simulate.c (ged_Simulate()) in the simphysics.cpp(run_simulation()) - we would be able not to recreate the bullet world at every step of the simulation but we won't be able to update mged at every step, we will get only the final position after the simulation completes. To update mged using librt we need to return from the run_simulation(), that's why we rectreate the simulation at every step with the state information stored in sim_params. + +At the moment we are supposed to use a custom ray-tracing algorithm that will detect the collisions between the geometry. The algorithm is commented out for the moment, it generated a series of errors and right now we are using the bullet default raytracing algorithms. The custom made algorithm it is registered in the simrt.c file. It is working with box-box, it should be tested for sphere-sphere and extended for arbitrary shapes. For arbitrary shapes the box will have contact points generated inside it, the contact points will be according to the shape the box encloses, not according to the box shape, so the box it will react according to the shape it represent and not like a cuboid. So for a sphere the box should roll on another box, penetrating it at the corners. + +The bullet collision manifold detection is done in 2 phase : broadphase collision and nearphase collision, and it is possible to register a callback for both phases. Broadphase algorithm gets called if 2 objects have their AABB overlapping, so for 2 spheres if the AABB is overlapping that does not necessarly mean they are collising, but they may collide in the next interations. Nearphase algortihm is for actual overlap. + +The code that shoots rays for the AABB is also in the simrt.c file and it shoot 4 rays for every bounding box.
本源码包内暂不包含可直接显示的源代码文件，请下载源码包。
