That means how do I use base DirectX or OpenGL api's to make a physics based destruction simulation? 
Will it be just smart rendering or something else is required?

Destruction generally has very little to do with the graphics API. It's all about your code manipulating the mesh data that forms your world.

If your game is designed such that destruction can only happen in a fairly controlled fashion, you can pre-split your meshes into multiple parts in your 3D modelling software, and then at runtime just detach the parts from each other when destruction occurs, and continue to simulate each part separately. 

If you need to be able to damage arbitrary meshes at runtime, you'll need some sort of CSG (Constructive Solid Geometry) algorithm to actually split meshes (lots of fun stuff here, as you'll need to delete triangles, insert new ones, fix up texture coordinates...).

You can also go the voxel direction, and build the whole world out of voxels. Then destruction consists of applying CSG operations to the underlying voxel data, and re-converting modified data to polygons. This is one of the more conceptually simple routes, but voxels in practice come with a surprising amount of additional complexity.

Some use-cases come to mind with using a graphics API for destruction. One can use GPU to accelerate physics simulation, which comes in handy if a model would be destroyed into many pieces. I imagine there are also GPU algorithms to compute voronoi noise for a nice procedural shattering effect. Also, a huge amount of voxels can be manipulated on the GPU. Also, rendering voxel based scenes could call for a nice GPU based algorithm.

Just food for thought, you can use just about any modern graphics API for these.

I can add here what generic destruction algorithm can look like (in short):

Given a mesh, and impact point(s) - which can be detected with any collision detection libraries - we generate a set of points on mesh surface (they are not randomly placed, but they are more dense around impact point, more sparse further away).

These are now used for generating voronoi diagram - for each point there will be a set of planes separating it (from neighboring points) - these planes are used to slice out part of mesh and also re-construct 'interior parts' of what is sliced out. These 'meshes' will be convex (assuming original mesh was convex - which is always a better alternative, and it's perferred to do convex de-composition of original mesh).

Each of these new objects also gets assigned convex collider and rigid body physics - co they behave physically.

This is also known as Voronoi shattering.

As you can see, nothing about 3D graphics api is actually mentioned, as any graphics api can then be used for rendering of objects after performing shatter. You're also free to use any physics library (you will most likely need basic collision detection and rigid bodies for realistic simulation).

Also as the algorithm is computationally intensive, you can actually pre-compute the shatter, and do just re-placement of original object with shattered objects (giving them collider and rigid body). Let me link you a video:

We've used this effect in game for Ludum Dare, shatter mesh was pre-generated. The actual activation of physics is delayed for specific parts of shattering object - due to design of the game.

On 3/3/2018 at 11:59 PM, swiftcoder said:

Destruction generally has very little to do with the graphics API. It's all about your code manipulating the mesh data that forms your world.

If your game is designed such that destruction can only happen in a fairly controlled fashion, you can pre-split your meshes into multiple parts in your 3D modelling software, and then at runtime just detach the parts from each other when destruction occurs, and continue to simulate each part separately. 

If you need to be able to damage arbitrary meshes at runtime, you'll need some sort of CSG (Constructive Solid Geometry) algorithm to actually split meshes (lots of fun stuff here, as you'll need to delete triangles, insert new ones, fix up texture coordinates...).

You can also go the voxel direction, and build the whole world out of voxels. Then destruction consists of applying CSG operations to the underlying voxel data, and re-converting modified data to polygons. This is one of the more conceptually simple routes, but voxels in practice come with a surprising amount of additional complexity.

So you are saying destruction is about how to use maths to manipulate geometry, vertices, indices per frame in rendering loop?

2 hours ago, ritzmax72 said:

So you are saying destruction is about how to use maths to manipulate geometry, vertices, indices per frame in rendering loop?

It's mainly about physics. If you want to do this yourself it will be by much the hardest part. You need a rigid body simulator, which consists of collision detection, solving for contact forces and so forth. So first you need to decide to spend at least a year on that, ore use a library. Physx is popular for massive destruction on GPU, you could use just that. 

Then, as Swiftcoder already said, decide if you can precalculate the pieces, or if you need to calculate destruction on the fly. Convex decomposition is no easy task either. Here's one library: http://kmamou.blogspot.co.at/2011/10/hacd-hierarchical-approximate-convex.html Physics engines probably provide their own. Doing this in realtime is very unlikely - you'd probably better cheat. (Let the original object disappear and repalce it with pieces that have a similar shape.)

There is nothing special about rendering. Doing the physics simulation on GPU might make sense. Usually this means again cheating where possible to keep things fast. There are many papers around about this. Approximating bodies with spheres, position correction, ...

So, either use libraries and make games, or spend years on research and hard work with risk of failure but lots to learn.

Both have their value, choose wisely... ;)